4

私は現在、データベースとの間で簡単なデータ操作を行うことができる Web アプリケーション (適度に最新) を設計しています。私はすでに潜在的な問題を考えています。

ユーザーが Web アプリにログインし、リポジトリからデータをロードするとします。(S)彼はデータを変更し、それをデータベースに書き戻したいと考えています。

標準化された方法で次のシナリオを防ぐ方法:

  • (S) 彼は 2 回ログインし、2 回目のセッションでデータを保存しましたが、これは最初のセッションから保存すると失われます。
  • 他のユーザーがデータをロードし、現在それを変更しているため、変更が上書きされる可能性があります。

2 フェーズ コミットとは言いたくありません。また、独自のバージョンを展開するつもりもありません。同じユーザーが 2 回ログインすること (ユーザー シングルトン) を防止し、厳密なアクセス許可管理と組み合わせることで、最初の問題を解決できます。しかし、ビジネス要件により、複数のエージェントが同じデータを表示および変更できる場合、私はまだ途方に暮れています。

読み取り中の仮定が保持される場合、書き込みが必要なデータをテストする差別化ライブラリ/アルゴリズムはありますか? 大規模な商用アプリケーションの場合、これは通常どのように解決されますか?

4

2 に答える 2

3

私は次の 2 つの主な戦略から選択します。

  • 楽観的ロック
  • 悲観的ロック

楽観的ロック:バージョン (番号) をオブジェクトの ID と共にリポジトリ (データベース) に保存します。新しいオブジェクトを保存する前に、上書きしようとしている古いオブジェクトのバージョンを確認します。バージョンが編集したオブジェクトのバージョンと一致しない場合は、保存を中止し、リポジトリ内のオブジェクトが変更されたことをユーザーに報告します。バージョンが一致する場合は、古いオブジェクトを新しいオブジェクトで上書きし、バージョンを増やします。

悲観的ロック: ユーザーが変更を開始する前にオブジェクトをロックします。オブジェクトがすでにロックされている場合は、現在のオブジェクトが別のユーザーによって編集されているというメッセージが表示されます。これは、DB ロックとステートフル Bean を使用する単一のトランザクションで行うか、別の使用定義フィールドを使用して行うことができます。

悲観的ロックは実装がより複雑ですが、楽観的ロック例外が発生した場合にユーザーがデータを入力してから再入力するのを防ぐため、ユーザー エクスペリエンスが向上します。

詳細については、 http://docs.oracle.com/javaee/6/tutorial/doc/gkjhz.htmlを参照してください。

于 2013-07-08T08:11:52.643 に答える
0

ほとんどの (つまりほとんどすべての) アプリケーションでは、これはOracle、MySQL、PostgreSQL など のACID データベースを使用して行われます。

于 2013-07-08T08:07:08.670 に答える