プロセス間の永続的なメッセージ キューイング メカニズムとして単純な sqlite DB を使用しています。特定の制限を超えた後にファイルサイズを縮小するには、「vacuum」コマンドを使用したいと考えていました。通常、これはすべてうまく機能しますが、掃除機をかけるときに「データベースがロックされています」というエラーが時々発生するだけです。
Web 上のさまざまなリソースを読んだ後、sqlite レベルでできることは何もないことがわかりました。
ただし、副次的な質問のほかに、「なぜそうなのか? 通常の busyHandler メカニズムを使用して必要なロックを取得しようとすると、何が問題になるのでしょうか?」私は、まったく同じ busyHandler メカニズムをアプリケーション レベルで実装するというアイデアを思いつきました。
ここで重要な質問: これで何か問題がありますか?
たくさんthx!!
これにしばらく取り組んだ後、バキューム処理を完全に削除することでアプリケーション ロジックを変更し、代わりに「pragma max_page_count」を使用して DB サイズを制限しました。注意すべき唯一のことは、これがセッション固有であるように思われることです。つまり、各 DB 接続後にプラグマを再度設定する必要があります。
元の問題に関して: @CL はほとんど正しいことがわかりました。実際、バキューム処理には標準のビジー ハンドラが含まれます。また、Linux でもこれはうまく機能しますが、Windows だけでは確実ではありません (偶然かもしれませんが、システムの速度が原因である可能性があります)。カスタムの busyHandler で少し printf() を使用すると、ほとんどの場合に呼び出されることがわかりますが、そうでない場合もあり、「プラグマ バキューム」は「DB ロック」を返すだけです。並行プロセスが同時にバキュームしようとしていることが原因である可能性があります (?) ...とにかく、再加工された設計はとにかくずっときれいで簡単です。
SQLite の組み込みの再試行メカニズムを使用することと、それを自分で実装することの間に大きな違いはありません。ただし、記述する必要のないコードを記述することは無駄な労力であり、バグが発生する可能性が高くなります。