Edit Diff Annotate History
Upload
List
Recent
Alias
Top
Help
EOOLUsingInSameInstance : Edit
Last updated: Fri Mar 30 22:07:46 +0900 2007
!同一のインスタンスでオプティミスティックロックを使う 同一インスタンス上で更新の競合を生じさせるには、直接SQL文を発行してデータ行を更新してしまうか、複数のEOObjectStoreCoordinatorを使うことでできます。 後者は競合を検出する方法として実装することもできますが、クライアントアプリケーションならともかくWebアプリケーションでは負荷が高くなってしまい実用的ではないでしょう。 セッションごとにコーディネータを用意するとなると、セッションの数だけスナップショットとデータベース通信チャネルが増え、オーバーヘッドが増大します。 そこで、デリゲートを使って同一インスタンス内で異なるEditingContext間の競合を検出するオプティミスティックロックを実装してみました (http://www.spice-of-life.net/archive/EOConflicts.tar.gz) 。 ページ最下部の"fireCustomOptimisticLocking"をクリックすると競合が発生します。 その他のリンクはデフォルトのオプティミスティックロックの動作確認です。 動作原理は簡単です。 オブジェクトをフェッチしたときのデータ行を保存しておき、更新時にEOFの保持するスナップショットと比較するだけです。 もし別のセッションやEOEditingContextでオブジェクトが変更されていなければ、フェッチ時のスナップショットとEOFのスナップショットが一致します。 そうでなければ例外を発生します。 他のアプリケーションやインスタンスでオブジェクトが変更されているときは、デフォルトのオプティミスティックロックにより例外が発生します。