問題タブ [optimistic-locking]

楽観的ロックと悲観的ロックの違いを理解しています。一般的にどちらを使用するかを誰かに説明してもらえますか？

また、クエリを実行するためにストアド プロシージャを使用しているかどうかによって、この質問に対する答えは変わりますか?

ただし、楽観的とは「読み取り中にテーブルをロックしない」ことを意味し、悲観的とは「読み取り中にテーブルをロックする」ことを意味します。

CakePHPを使い始めたばかりですが、楽観的ロックスキームを実装するためのサポートが見つかりません。私が見つけた最も近いものは、このCakePHPブログ投稿へのコメントで、2008年6月にはサポートされていなかったというものでした。

それが変更されたかどうか、または誰かがそれを自分で実装する方法に関する拡張機能またはチュートリアルを公開したかどうかを誰かが知っていますか？

楽観的ロックの説明については、この回答を参照してください。

どういうわけか、私はいつも金曜日にこれらを手に入れます。

以前の質問は同じ問題に関するものでしたが、今では少し絞り込むことができます。

私はこれを理解しようと一日中遊んでいます。次のように指定されたlock_version列を持つテーブルがあります。

そして、私はこのようなことをします：

次に、1番目と2番目が同じオブジェクトを参照していることを確認します。それらのIDは同じであり、mysqlコマンドラインツールを使用してデータベースにその行が表示されます。

今のところ問題ありません。ActiveRecord::StaleObjectError例外が正しく発生します。 ただし：

...そして何も起こりません。正しい（スローされた例外）動作が得られるのは、最初と2番目のlock_versionが0の場合だけです。ただし、最初の保存後は、再び0になることはありません。いったいこれで何が起きているのでしょうか？

私はruby1.8.6とアクティブレコード2.2.2を使用しています

ありがとう...

asp.net MVC アプリケーションに楽観的ロックを実装し、監査追跡を提供しようとしています。

監査フレームワークは、SubmitChanges 中に DataContext.GetModifiedMembers を呼び出せることに依存していますが、これは理にかなっていると思います。

楽観的ロックでは、ROWVERSION タイムスタンプが使用され、base64 にシリアル化され、ビューの非表示フィールドに配置されます。

私の編集アクションは次のようになります。

これを行うと、DataContext.GetModifiedMembers は、データベースと提供された値の間で変更されたものだけでなく、MyType のすべてのプロパティを常に返すため、監査が中断されます。具体的には、すべてのプロパティが新しい値から新しい値に変更されたものとして返されるため、リストに対して巧妙なことを行うことはできません。

アタッチする前に最初にオブジェクトをロードしようとしましたが、これにより重複キーの例外が発生します。

次に、UpdateModel を使用してみました。

これは監査で機能しますが、楽観的ロックは失敗します。ChangeConflictException ではなく、InvalidOperationException を取得します。これは、UpdateModel が concurrentTS フィールド (明らかに読み取り専用) を変更しているためです。

私は何を間違っていますか？

サーバー上にオブジェクト マップ (データベースのコンテンツに基づいて相互に関連する顧客、注文、アイテムを表すオブジェクト) があり、ユーザーが操作しているブラウザーでそのオブジェクト マップの最新バージョンを維持したいと考えています。データを表示します。

より多くのユーザーが同じオブジェクト マップに同時にアクセスして変更できるため、クライアントとサーバーとの同期を維持する方法が必要です。

私のサーバー環境は .net/asp.net 3.5 sp1 に基づいており、クライアントはブラウザー (html/javascript) で実行する必要があります。クライアント側でデータバインディング機能と監視可能なコレクションのためにasp.net ajax 4.0を使用し、サーバーで.net riaサービスまたはado.netデータサービスなどを使用することを検討しています。

誰かがブログ投稿/チュートリアル/研究論文/記事/あなたの名前を知っているか、そのトピックについて知っている場合は、リンクまたはコメントをいただければ幸いです。

よろしく、エギル。

私は DevExpress XPO ライブラリの長年のユーザーです。多くの優れた機能を備えていますが、いくつかの弱点があります。

1. 既存のオブジェクトを保存すると、すべてのプロパティが更新クエリで送信されます。変更は、プロパティごとではなく、オブジェクトごとに追跡されます。
2. オプティミスティック ロックは、列ごとではなく、オブジェクトごとに行われます。
3. 楽観的ロック例外が発生した場合、競合の性質を説明するコンテキストは提供されません。あなたの唯一の本当の対応は、操作を失敗させるか、それを再現してループで再試行することです。
4. XPQuery の LINQ サポートは非​​常に弱いです (少なくとも、私たちが使用している 8.1 では)。したがって、タイプセーフではない XPView や、必ずしも必要ではない列を返す可能性のある XPCollection を使用せざるを得ないことがよくあります。

LINQ to SQL がロックの最適化と更新の競合の処理を実装する方法について読んだ後、私は納得しました! 列レベルの楽観的ロックを実装し、テーブルに列を追加する必要がない点が気に入っています。競合の正確な性質を調べて処理できることは素晴らしいことです。また、列ごとの変更を追跡するという事実により、更新クエリがより効率的になるはずです。

もちろん、実際のアプリケーションで LINQ to SQL をまだ使用したことがないので、実際に比較できるかどうかはわかりません。また、XPO で楽しんでいる次のようないくつかの機能に類似したものがあるかどうかも不明です。

1. 自動スキーマ更新 (私たちはオブジェクト設計がデータベース構造を逆にするのではなく駆動すると信じており、これによりソフトウェアの展開が大幅に簡素化されます)
2. 継承の実装方法に関する 2 つのオプション (同一テーブルまたは 1 対 1 のテーブル リレーションシップ)
3. インメモリ ストレージのサポート (単体テストで LINQ to Objects を代用できると思いますが)
4. ストレージ プロバイダーのカスタマイズ (これにより、XPO クエリに NOLOCK サポートを追加できました)

コードの異なる部分に 2 つの ORM を一時的に使用する、試験的な部分的な移行を行う予定です。XPO と LINQ to SQL の両方を実際に使用した経験のある方はいますか? それらは実際にどのように比較されますか？具体的には、LINQ to SQL に欠けていて、コードの移行が困難になる機能をご存知ですか?

ああ、LINQ to Entities についても気にする必要がありますか? 必要なものよりもはるかに複雑に見えます。

私には 2 つのエンティティがParentありChildます。1 対多の関係にあります。はParentバージョン管理されています。つまり、@Version フィールドがあります。私の目標は、バージョンのParentとChildエンティティの両方への変更を同期することです。Parent

たとえば、あるスレッドが を更新しParent、別のスレッドがその の 1 つを更新するChildと、OptimisticLockException が発生します。

出来ますか？

Childのバージョンをインクリメントする @PreUpdate に @PreUpdate を追加しようとしましたParentが、Hibernate はバージョンをチェックした後にのみリスナーを実行するように見えるため、トランザクションはとにかく正常にコミットされるため、役に立ちませんでした。

可能であれば、どのように実装できますか？

エンティティのバージョン属性を使用したオプティミスティックロックは正常に機能し、実装が簡単です。

エンティティには、次のタイプのプロパティがあります。

ここまでは順調ですね。これで、サービスメソッドは上記のエンティティのデータ転送オブジェクト（DTO）を返します。これは、ビューがHTMLで表示します。更新ページの場合、VERSION属性はHTMLの非表示フィールドに格納され、フォームとともに送信されます。

目的は、versionプロパティを使用して、表示される情報に古いバージョンが付随している場合にユーザーの更新が失敗するようにすることです。

コントローラは、更新された情報（バージョンプロパティを含む）を含むDTOを使用してサービスメソッドを呼び出すことでユーザーの更新要求に応答し、サービスメソッドはデータアクセスオブジェクト（DAO）を使用して変更を永続化します。

問題は、copyProperties（...）によってエンティティにコピーされたバージョンプロパティがHibernateによって尊重されないことです。次のフォーラムで理由を突き止めました：https ：//forum.hibernate.org/viewtopic.php？f = 1＆t = 955893＆p = 2418068

つまり、load（）が呼び出されると、Hibernateはバージョンプロパティをセッションキャッシュにキャッシュし、その値が後で何に変更されてもかまいません。これが正しい動作であることに同意しますが、BossesからHTMLフォームプロパティを介してバージョンを渡すように指示されています（これに適したパターンがある場合は、ぜひ聞いてください）。

私が今探求している解決策の1つは、更新が行われる前に、hibernateTemplate.evict（simpleEntity）を使用してバージョンが設定された後、セッションからエンティティを削除することです。これがうまくいくことを願っていますが、効率的ではないようです。

セッションキャッシュからだけでなく、インスタンス自体のバージョンプロパティを確認するようにHibernateに依頼したいと思います。

回答ありがとうございます！

--LES

CakePHPには楽観的ロックのサポートがないように思われるので、私はそれを実装する動作を構築することに挑戦しています。動作を少し調べた後、beforeSaveイベントでクエリを実行して、バージョンフィールドが変更されていないことを確認できると思います。

ただし、更新ステートメントのWHERE句をから変更してチェックを実装したいと思います。

に

このようにして、バージョンを読み取ってから更新を実行するまでの間にデータベースレコードを変更する他の要求について心配する必要はありません。また、2回ではなく1回のデータベース呼び出しを実行できることも意味します。

DboSource.update()メソッドが条件をサポートしていることがわかりますがModel.save()、条件を渡すことはありません。

私にはいくつかの選択肢があるようです：

1. チェックインを行い、beforeSave()防弾ではないという事実を受け入れてください。
2. CakePHPのローカルコピーをハックして、の配列conditions内のキーをチェックし、それをメソッドに渡します。optionsModel.save()DboSource.update()

現在、私は2番目のオプションに傾倒していますが、それは、他のユーザーが私のハックをフレームワークに適用しない限り、他のユーザーと自分の行動を共有できないことを意味します。

より簡単なオプションを逃したことがありますか？

Java サーバー アプリケーションをクラスタ化/配布するための最良の方法は何ですか? アプリケーション サーバーとデータベース サーバーを追加することで、水平方向にスケーリングできるアプローチを探しています。

• この種の問題に取り組むために、どのような技術 (ソフトウェア エンジニアリング技術または特定の技術) を提案しますか?
• パーシスタンス レイヤーを設計して多数のリーダー/ライターにスケーリングするために使用する手法は何ですか? アプリケーション トランザクションをスケーリングし、共有データへのアクセスをスケーリングします (最善の方法は、共有データを排除することです。共有データを排除するためにどのような手法を適用できますか)。
• トランザクションの読み込みが多いか書き込みが多いかによって、異なるアプローチが必要になるようですが、「読み込み」でも効率的な「書き込み」が多いアプリケーションを最適化できればいいと思います。

「最良の」ソリューションは、単一ノード用の Java アプリケーションを作成し、できれば共有データへのアクセス/ロックの詳細のほとんどを「隠す」ことができます。

分散環境で最も困難な問題は、共有データにアクセスする複数のトランザクションを持つことです。同時トランザクションには 2 つの一般的なアプローチがあるようです。

1. 明示的なロック(これは非常にエラーが発生しやすく、分散システム内の複数のノード間で調整するのに時間がかかります)
2. ソフトウェア トランザクショナル メモリ(STM) 別名楽観的同時実行性。共有状態が変更されたことが検出された場合、コミット中にトランザクションがロールバックされます (トランザクションは後で再試行できます)。どのアプローチがより適切にスケーリングし、分散システムのトレードオフは何ですか?

私は、次のようなスケーリング ソリューション (およびスケーリング方法の例を提供する一般的なアプリケーション) を研究してきました。

1. Terracotta - Java メモリ モデルを拡張して、Java の同時実行ロック メカニズム (同期、ReentrantReadWriteLocks) を使用して分散共有メモリを含めることにより、「透過的な」スケーリングを提供します。
2. Google App Engine Java - どのサーバーがトランザクションを処理するかを分散し、BigTable を使用して永続データを格納する「クラウド」サーバー間で分散される Java (または python) アプリケーションを作成できます (共有にアクセスするトランザクションがどのように行われるかはわかりません)効果的にスケーリングできるようにデータまたはロック競合を処理します)
3. Darkstar MMO サーバー- Darkstar は、Sun のオープン ソース MMO (大規模マルチプレイヤー オンライン) ゲーム サーバーであり、スレッド トランザクション方式でトランザクションをスケーリングし、特定のトランザクションを特定の量だけ実行してコミットし、時間がかかる場合はロールバックします (ソフトウェア トランザクショナル メモリ)。彼らは、スケーリングのためにマルチノード サーバーのセットアップをサポートするための調査を行ってきました。
4. Hibernate の楽観的ロック- Hibernate を使用している場合は、楽観的同時実行サポートを使用して、ソフトウェアのトランザクション メモリタイプの動作をサポートできます。
5. Apache CouchDBは、メッシュ構成の多くのリーダー/ライター DB に自然に「スケーリング」することになっています。(データのロックやトランザクションの分離を管理する方法の良い例はありますか?):
6. JCache - Google appengine で memcached にアクセスし、他の頻繁に読み取られるデータをキャッシュするために使用できる一般的なクエリに結果をキャッシュすることにより、「読み取り」負荷の高いアプリをスケーリングします。

Terracotta は、(@Root オブジェクトと @AutoLockRead/Write メソッドを定義した後)スケーリングをサポートするように既存のサーバー アプリケーションを「簡単に」変更できるという点で、最も完全なソリューションのようです。問題は、分散アプリケーションから最大限のパフォーマンスを実際に引き出すことです。分散システムの最適化は、オブジェクト アクセスがネットワーク I/O によってブロックされる可能性があることを知って設計する必要があると考えた後ではないのです。

適切にスケーリングするには、データのパーティション分割と、特定の「実行ユニット」(CPU コア -> スレッド -> 分散アプリケーション ノード -> DB マスター ノード) のようなトランザクションの負荷分散に常に帰着するようです。

クラスタリングによってアプリを適切にスケーリングするには、データアクセスの読み取り/書き込みに関してトランザクションを分割できる必要があるようです。アプリケーション データ (Oracle、Google BigTable、MySQL、データ ウェアハウス) を配布するために人々が思いついたソリューションと、一般的にパーティション化されたデータ (多くの書き込みマスター、より多くの読み取り DB など) をどのように管理しますか?

データ永続レイヤーのスケーリングに関して、データを多くのリーダー/多くのライターにパーティション分割するという点で、どのタイプの構成が最適にスケールアウトされますか (通常、特定のユーザー (または一般的にあなたのコア エンティティである任意のコア エンティティ) に基づいてデータをパーティション分割します) 「ルート」オブジェクト エンティティ) が単一のマスター DB によって所有されている)