問題タブ [optimistic-locking]

楽観的ロックと悲観的ロックが何であるかは知っていますが、Java コードを作成するときはどのようにしますか? Java で Oracle を使用しているとします。これを行うのに役立つ JDBC のメソッドはありますか? これをどのように構成しますか？任意のポインタをいただければ幸いです。

相互運用性のために設計されたオプティミスティック ロック/オプティミスティック同時実行制御(OCC)用の Web サービス標準 (WS*) はありますか?

WS-AtomicTransactionなど、悲観的同時実行制御メカニズムに関連する標準は多数ありますが、私が知る限り、楽観的ロックに関連するバージョンまたはタイムスタンプ処理の機能は提供されていません。

楽観的ロックと WCFに関する記事を 1 つ見つけましたが、市長の標準はありません。そのようなものはありますか、または他のサンプルやパターンをお勧めしますか?

バックグラウンド

（SOAP）WebサービスがありBookService、図書館の本を管理していると仮定します。Book情報モデルでは、エンティティに次の属性があると想定しています。

• id
• author
• publisher
• title
• shelfId

データを操作するために、4つのWebサービス操作が定義されています。

• AddBook
• GetBook
• UpdateBook
• DeleteBook

要求メッセージと応答メッセージは、操作ごとに定義されています。ただし、更新メッセージXMLスキーマの設計はより複雑です。私たちは以下の資質を達成したいと考えています。

• R1：属性の以前の値をリセット/削除する可能性。たとえば、本をライブラリに保持しなくなったshelfIdため、その特定の本の属性の属性値をリセット/空にする/削除したいとします。
• R2：Webサービスでのおしゃべりを避けてください。アンチパターンのChattyServicesを参照してください。
• R3：同時実行制御とオプティミスティックロックに関する将来の要件に備えます。古い情報に基づいて更新が行われるリスクを最小限に抑える（または削除する）ことができます。

代替案の設計

更新メッセージを設計するための3つの市長の選択肢があり、そのうちの1つにはいくつかのサブオプションがあります。

1. ビジネスドキュメント全体を送信します。省略された要素（minOccurs="0"スキーマ内にある）または明示的にnullに設定された要素、つまり<shelfId xsi:nil="true"/>、は、前の値の削除として解釈されます。
2. 変更を強調表示するか、差分のみを送信します。
   1. ビジネスドキュメント全体を送信しますが、この目的に固有の属性を使用して、変更された要素にマークを付けます。例：<author dirty="true">Hemingway<author/>。次に、サービスのプロバイダーは、ダーティとしてマークされた要素のみを更新し、他の要素を無視します。
   2. メッセージスキーマで、識別子を除くすべての要素をに設定しidますminOccurs="0"。コンシューマーは、変更される要素のみを送信します。省略された要素は、意味的に削除として解釈されてはなりません。値を削除するには、明示的なXMLNULL値を使用する必要があります。例：<shelfId xsi:nil="true"/>。
   3. ビジネスドキュメント全体を送信するだけでなく、以前に読んだドキュメントのコピーも送信します。次に、プロバイダーは2つのドキュメントを比較し、新しいドキュメントと以前のドキュメントが異なる属性のみを更新できます。
3. 複数の操作を定義します。1つの操作だけを使用するのではなく、更新UpdateBookする必要があると思われる要素に基づいて複数の操作を定義します。これらのそれぞれには必須の要素のみがあり、要素を削除するには、XMLの明示的なNULLを使用します。UpdateBookAuthorUpdateBookPublisher<shelfId xsi:nil="true"/>

討論

Alt 3Bookには、理解しやすいという利点がありますが、エンティティ内の複数のフィールドを更新する必要がある場合に、コンシューマーが複数の操作を呼び出す必要があるという欠点があります。これにより、サービスが「おしゃべり」になり（上記のR3を参照）、パフォーマンスが低下します。

Alt2はAlt1よりも複雑ですが、楽観的同時実行制御に関連するAlt2にはいくつかの利点があります。

• 各フィールドのタイムスタンプ/バージョンを使用した楽観的ロックがデータベースに保存されている場合（例authorVersion）=> Alt 2は、複数のユーザーが同じのとなどの異なる部分を同時に変更できるようにするとauthor同時に、障害が発生するリスクを減らす方法を提供します。publisherBook
• 全体に対して単一のタイムスタンプ/バージョンを使用した楽観的ロックがBookデータベースに保存されている状況の場合=> Alt1に対するAlt2の実際の利点はありません。更新によって1つのフィールドのみが変更された場合でも、リクエストのバージョン番号が古すぎると障害が発生します。
• 同時実行制御または楽観的/悲観的ロックが使用されていない状況の場合=> Alt2は、 Alt 1よりも古いデータで上書きするリスクが少なくなりますが、他の一貫性のない変更によって問題が発生する可能性があります。

Alt 2（およびAlt 3）がAlt1よりも有利であるさらに別の状況があります。消費者は、エンティティに関するすべてのデータを保存できない場合があります。たとえば、棚の情報を更新するときに、著者の情報を追跡（キャッシュ）する必要がなく、棚だけを追跡する必要がある場合、棚から本を選ぶロボットをより効果的にプログラムできます。Book

コンシューマーがバージョン番号やタイムスタンプの代わりに以前のバージョンのコピー全体を送信するAlt2.3のアプローチの利点は、バージョン番号やタイムスタンプにデータベース内の専用の列が必要ないことです。

要約すると、 Alt2.2はほとんどの場合最も魅力的なもののように見えます。ここでの課題は、XMLを逆シリアル化するフレームワークが、除外された要素と明示的にNULLに設定された要素を区別できなければならないこと<shelfId xsi:nil="true"/>です。このトピックに関する投稿はこちらをご覧ください。

質問

どちらの選択肢を選びますか？他のより良い選択肢がありますか？議論についてどう思いますか？

GridViewControl のメソッドの 1 つで、データベース内のレコードを更新しようとしています。OptimisticLockException が発生しています。私のデータベースには、この写真に4つの日付フィールド（dZadOpenDateTime、dZadCloseDateTime、dCreatedDateTime、dChangedDateTime）が表示されていますhttp://imageshack.us/photo/my-images/854/exception.jpg/

この例外を処理する方法のヒントを教えてください。

楽観的ロックに ETag を簡単に使用できる Django 用の REST フレームワークを選択しようとしています。私は Django-pistons と Django Rest Framework ライブラリを調べる予定ですが、GPL 以外のソリューションに対してオープンです (企業のライセンス要件により、それらを使用することはできません)。

私のアプリケーションは、SQLAlchemy モデル (Django モデルではない) からのデータを JSON/YAML 形式で販売しています。モジュロ ETag の問題は、Django Rest Framework でうまく機能しています。ただし、ビューに ETag ヘッダーを適用する簡単な方法がわかりません。

私の見解では、これを行いたいです：

1. 応答があれば、成功時に送信する応答ヘッダーに ETag を簡単に追加できます。これはモデルに依存するため、私が計算する必要があります。応答値などをハッシュするだけでは不十分です。

2. POST/PUT で、受信した ETag が送信したものと一致することを確認するか、要求を拒否します。

少し面倒なのはステップ 1 です。どの REST フレームワークがこれを最も簡単にするのか、またそれを達成するための最良の方法が何かもわかりません。

JSF と JPA で実装された Web アプリケーションがあります。UI では、操作全体を「保存」する前に、さまざまなエンティティを更新できます。保存操作中に 2 人のユーザーがデータを交差させた場合、そのうちの 1 人が楽観的ロック例外を取得しますが、これは問題なく適切です。ただし、UI の適切な行にマーカーを表示するために、例外の処理中にどの特定のエンティティが楽観的ロック例外を引き起こしたかを判別できるようにしたいと考えています。オプティミスティック ロック例外のキャッチ ブロックで eclipselink を使用して、オプティミスティック ロック例外の原因となったエンティティを特定する方法はありますか?

環境：

私はそのUserエンティティを持っています:

ユーザーを一覧表示する検索ページがあり、ユーザーをクリックして編集します ( userIdURL に入力します)。

編集フォームでは、そのエンティティのフィールドをサーバーに保存し、ユーザーを保存するときにこれを行います。

質問：

したがって、Hibernate での楽観的ロックを正しく理解していれば、ブラウザーで 2 つのタブを開いて同じユーザーを編集し、最初のタブでログインを更新し、次に2 番目のタブでログインを更新すると、OptimisticLockException ?

実際、これは私のアプリケーションには当てはまりません...私は、2回目の更新で最初の編集によって更新されたform.getVersion()としても、両方のケースで同じ値を返すことを確認しました。user.version

何か不足していますか？

EntityManagerが生成されます(したがって、マージしようとすると@RequestScoped2 つの異なるにいます...)。EntityManager

私はentityManager.lock(user, LockModeType.OPTIMISTIC_FORCE_INCREMENT)前にやろうとしましたentityManager.merge(...)（ここで言ったように）が、助けにはなりませんでした。

JBoss 7.0.2.Final (Hibernate 4 を使用) で Seam 3 を使用しています。

ASP.NET MVC アプリケーションの対応するコントローラー内でtry-catchブロック ( catch/handle を目指して) を使用してリポジトリへの呼び出しをラップする必要がありますか、それともリポジトリ実装内で行う必要がありますか?StaleObjectStateException

また、例外をどのように処理すればよいか、ユーザーに通知してください。私が理解している限り、ロールバックは意図されていませんか?

ありがとう！

Java/JDBC と MySQL を使用してアクティブ レコード パターンを実装し、並行処理のための楽観的ロックを実装しようとしています。

これで、テーブル内のすべてのレコードに「version_number」フィールドがあり、更新のたびにインクリメントされます。

これを実装するには2つの戦略があるようです：

1. アプリケーションは、データを要求すると、各オブジェクト (レコードなど) の対応するバージョン番号も格納します。更新時に、バージョン番号がデータ層に「送信」され、UPDATE...SET...WHERE クエリで楽観的ロックに使用されます。
2. アプリケーションはバージョン番号を保存しませんが、(データ行全体ではなく) オブジェクトの一部のみを保存します。楽観的ロックを成功させるには、データ層 (アクティブなレコード) が最初に DB から「行」をフェッチし、バージョン番号を取得してから、同じ UPDATE...SET...WHERE クエリを起動してレコードを更新する必要があります。

前者では、「最初のフェッチ」とその後の更新があります。後者の場合、「最初のフェッチ」だけでなく、更新の直前にもフェッチがあります。

問題はこれです:設計上、どちらがより良いアプローチですか? バージョン番号を含むすべてのデータを Web アプリケーションのフロントエンド (Javascript/HTML) に保存することは大丈夫ですか? 安全ですか? それとも、更新前に読み取りのパフォーマンス ヒットを取得するほうがよいでしょうか?

この設計を実装する「正しい方法」はありますか? アクティブ レコードの現在の実装 (Ruby、Play、ActiveJDBC など) がこれをどのように処理しているかはわかりません。JDBC で「そのまま」実装する場合、この場合の正しい設計上の決定は何ですか?

Hibernate 4.1.0 が提供する Spring 3.1/JPA 2 を使用します。

基本的な監査機能 (更新タイムスタンプ、バージョン番号など) を提供するすべてのエンティティの基本クラスがあります。他のアプリケーションがデータベースにアクセスするため、これらはトリガーを介して設定する必要があります。

私のマッピングは次のようになります。

このorg.hibernate.engine.internal.increment(...)メソッドは、トランザクションをコミットするときに常に呼び出され、StaleObjectStateException.

奇妙なことGenerationTime.NEVERに、バージョン列を設定すると、休止状態は引き続きバージョンをインクリメントしますが、適切に持続します。問題は、データベースのバージョンが更新されない場合 (テーブルに変更がない場合など) であっても、マージから返されるバージョンがデータベースの値よりも 1 高くなり、その後の保存で明らかに問題が発生することです。

私の期待は、GenerationTime.ALWAYS休止状態にバージョンをインクリメントしようとせず、データベースに依存してそうするように指示し、次に挿入/更新後に更新された値を選択することです。

私の理解と実装のどこが間違っているのか、誰か教えてもらえますか?