1

h2 機能ページによると、H2 ドキュメントに矛盾が見られます

データベース ファイルのロック

[...] 次のファイル ロック方法が実装されています。

デフォルトの方法は FILE で、ウォッチドッグ スレッドを使用してデータベース ファイルを保護します。ウォッチドッグは毎秒ロック ファイルを読み取ります。

2 番目のメソッドは SOCKET で、サーバー ソケットを開きます。ソケット方式では、毎秒ロック ファイルを読み取る必要はありません。ソケット方式は、データベース ファイルが 1 台の (常に同じ) コンピュータによってのみアクセスされる場合にのみ使用してください。

3 つ目の方法は FS です。これは、FileChannel.lock を使用したネイティブ ファイル ロックを使用します。

ファイルをロックせずにデータベースを開くこともできます。この場合、データベース ファイルを保護するのはアプリケーション次第です。そうしないと、データベースが破損します。

上記のことから、書き込み時の同時実行性を手動で気にせずに、異なるコンピューター間でリモート ファイル システム上のデータベースを共有することはできないように思われます。ただし、高度なページでは、シリアル化されたファイルをロックする 5 番目のメソッドを追加して、次のことを許可する必要があります。

このロック モードでは、同じデータベースへの複数の接続を開くことができます。接続は、複数のプロセスや異なるコンピューターから開くことができます。データベースへの書き込み時に、アクセスは内部で自動的に同期されます。

矛盾があるというのは正しいですか？または、シリアル化されたファイルのロックを誤解しましたか?

4

1 に答える 1

2

シリアル化されたファイルのロックは、「この機能は比較的新しいものです。本番環境で使用する場合は、ユース ケースが十分にテストされていることを確認してください (可能であれば、自動化されたテスト ケースを使用してください)。」という文書のように、実験として実装されました。これが、通常のドキュメントに追加されなかった理由です。

リモート ファイル システムでデータベースを共有することはお勧めしません。H2 とは関係ありませんが、私は NFS の実装で悪い経験をしました。あるケースでは、ファイルのロックが壊れていました (クラッシュして再起動した後も、ファイルはまだロックされていました)。あるケースでは、NFS 実装のバグが原因で、同時アクセスが中断されました (1 つのクライアントが別のクライアントによる変更を認識しませんでした)。複数のケースで、信頼性の低いネットワーク接続が原因で、ファイルが時々閉じられました。そして多くの場合、パフォーマンスは悪かった。Office ファイル、写真、動画の共有などの特定のユース ケースでは、これらすべてが問題ない場合があります。しかし、データベースの場合、これは良くありません。

于 2013-09-20T15:15:35.320 に答える