| MozillaZine.jp フォーラム https://forums.mozillazine.jp/ |
|
| Firefox3.0のformhistory.sqliteがずっとLOCKされている https://forums.mozillazine.jp/viewtopic.php?f=28&t=8505 |
ページ 1 ／ 1 |
| 作成者: | teramako [ 2009年5月10日(日) 01:06 ] |
| 記事の件名: | Firefox3.0のformhistory.sqliteがずっとLOCKされている |
Firefox終了時にプロファイルフォルダ内にある、SQLiteDBのVACUUMとREINDEXを行おうとしています。
という手順です。 しかし、常にformhistory.sqiteの部分でNS_ERROR_FILE_IS_LOCKの例外が投げられてしまいます。xpcom-shutdownはFirefox終了時に投げられるイベントの中でも最後の類になのでそのころにはDBへのアクセスはないと思っているのですが... 原因を知っている方は教えていただけないでしょうか。 私の日記（http://d.hatena.ne.jp/teramako/20090508/p1）に探った結果があるのですが、LOCKされている原因にはたどりつけていません。 |
|
| 作成者: | Piro [ 2009年5月10日(日) 02:39 ] |
| 記事の件名: | Re: Firefox3.0のformhistory.sqliteがずっとLOCKされている |
試しにSQLite Managerでformhistory.sqliteに接続してみましたが、通常時（終了処理中とかではなく）だと普通に接続できますね。 SQLite Manager内部では普通にOpenDatabaseしてるだけなので、多分teramakoさんがやろうとしてることと同じ事をしてるはずなんですが、何故teramakoさんの場合はうまく行ってないのか…… |
|
| 作成者: | teramako [ 2009年5月10日(日) 04:58 ] |
| 記事の件名: | Re: Firefox3.0のformhistory.sqliteがずっとLOCKされている |
Piro さんが書きました: 試しにSQLite Managerでformhistory.sqliteに接続してみましたが、通常時（終了処理中とかではなく）だと普通に接続できますね。
SQLite Manager内部では普通にOpenDatabaseしてるだけなので、多分teramakoさんがやろうとしてることと同じ事をしてるはずなんですが、何故teramakoさんの場合はうまく行ってないのか…… すみません、ちょっと説明が足りませんでした。 OpenDatabaseはできます。SELECTもできます。しかし、VACUUM の実行で例外が投げられます。因みにINSERTも同様にLOCKされていてできませんでした。 VACUUMはDB全体に影響するので排他ロック相当のものが必要と思いますが、他のトランザクションが実行中であるためにVACUUM側でロックの取得ができず、例外が投げられているのではないかと思っています。 通常時であれば納得のいく話なのですが、xpcom-shutdownが投げられる段階になってもロックされているという例外が投げられてしまうのが腑に落ちないのです。 拡張のせいだったり、現在のプロファイルのせいだったりするかもしれませんので、新規プロファイル上でも試してみたいと思います。 |
|
| 作成者: | Piro [ 2009年5月10日(日) 06:33 ] |
| 記事の件名: | Re: Firefox3.0のformhistory.sqliteがずっとLOCKされている |
これまたSQLite Managerでの実験結果ですが、Shiretokoで INSERT INTO moz_formhistory (fieldname, value, timesUsed, firstUsed, lastUsed) VALUES("searchbar-history", "foobar", 1, 0, 0) としてみたところ、特にエラーも起こらず成功してしまいました。 終了処理のタイミング特有の問題なのかもしれませんね。 ちなみにVACUUMは、Shiretokoだとエラーにならず、Firefox 3.0.10だとエラーになりました。 |
|
| 作成者: | teramako [ 2009年5月10日(日) 13:43 ] |
| 記事の件名: | Re: Firefox3.0のformhistory.sqliteがずっとLOCKされている |
Piroさん、Shiretokoでの調査ありがとうございます。 Shiretokoだと大丈夫なんですね。 Shiretokoで思いついて、MXRでnsFormHistoryのソースを見比べてみたところ、Fx3.0のソース(http://mxr.mozilla.org/firefox/)とMozilla 1.9.1(http://mxr.mozilla.org/mozilla1.9.1/)のソースに違いがあることを発見しました。（当初、勘違いでMozilla 1.9.1のソースのみを読んでいて問題の発見が遅れました。すみません） Fx3.0の方にはわざとトランザクションを維持させていると思われるコードがありました。(http://mxr.mozilla.org/firefox/source/toolkit/components/satchel/src/nsStorageFormHistory.cpp#745) コード: 745 // nsFormHistory::StartCache
746 // 747 // This function starts the dummy statement that locks the cache in memory. 748 // As long as there is an open connection sharing the same cache, the cache 749 // won't be expired. Therefore, we create a dummy table with some data in 750 // it, and open a statement over the data. As long as this statement is 751 // open, we can go fast. 752 // 753 // This dummy statement prevents the schema from being modified. If you 754 // want to add or change a table or index schema, you must stop the dummy 755 // statement first. See nsNavHistory::StartDummyStatement for a slightly 756 // more detailed discussion. 757 // 758 // Note that we should not use a transaction in this function since that 759 // will commit the dummy statement and everything will break. 760 // 761 // This function also initializes the cache. また、StopCache(StartCacheで作成したstatementのresetをする関数)もありましたが、どこからも呼ばれないみたいです。よって最後の最後までトランザクション張りっぱなしです。 反対にMozilla 1.9.1側のソース(http://mxr.mozilla.org/mozilla1.9.1/source/toolkit/components/satchel/src/nsStorageFormHistory.cpp)にはこれら処理はありませんでした。 これでFx3.0でVACUUMが失敗することも、Shiretokoでは問題ないことも説明がつきそうです。 問題の解決は無理そうですけど。。。 一応納得のいく結果となりましたので、これでクローズとしたいと思います。テスト等々ありがとうございました。 |
|
| ページ 1 ／ 1 | All times are UTC + 9 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|