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では問題ないことも説明がつきそうです。
問題の解決は無理そうですけど。。。
一応納得のいく結果となりましたので、これでクローズとしたいと思います。テスト等々ありがとうございました。
ログイン
ユーザー登録
FAQ
検索
