[jpa:95] Re: Kuina-Dao利用時にオブジェクトのネットワークを一括でロックする方法

[Nobuaki Ito]

中村さん、equals()の話も含め、どうもありがとうございます。


KUINA-Dao(JPA)の場合、Lockのメソッドは楽観的排他制御になるという事ですね。わかりました。
今回の場合、それだと、自分の仕事に失敗して泣きを見るユーザーが結構居そうなので（笑）、フレームワーク側ではなくアプリケーション側でロックの仕組みを実装する方向で検討してみます。


08/01/11 に Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]> さんは書きました:
>
> 中村(taedium)です。
>
> > 考えついたのは次の２つですが、メリット／デメリットの判断が自分では難しいです。
> > １）Kuina-DaoのreadLock() / writeLock()
> > メソッドで、根元のエンティティをロックする。（ただ、ロックを外すタイミングがよくわかりません。）
> > ２）ロックテーブルのようなものを作って、ユーザーレベルでロックを実装する。
>
> 楽観的排他制御と業務排他制御のどちらが望ましいかに
> よるのではないでしょうか。
>
> 1)の場合は、 writeLock()が適切だと思いますが、これは楽観的排他制御です。
> この方法では、更新時、アプリで必ずルートのエンティティをwriteLock
> してからルート以下の階層構造のエンティティを修正することになります。
> 複数人が同時に同じデータを修正し始めることができますが、
> 実際に更新に成功するのは一人になります。
> それ以外のユーザーは更新に失敗します。
>
> 楽観的排他制御はエンティティのバージョン番号により行われるので
> ロックを外すといった操作はいらないです。
>
> 2)は業務排他制御ですね。
> この場合は、特定のユーザーにロックが明示的に取得されてから
> そのユーザーによる修正と更新が行われることになると思います。
> この間、他のユーザーは修正作業に着手できません。
>
> こちらは明示的にロックを解除する操作が必要ですね。
>
>
> 更新の競合が許容できるなら1)、できないなら2) といったところでしょうか。
> --
> Toshihiro Nakamura
>
> _______________________________________________
> jpa mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/jpa
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: http://ml.seasar.org/archives/jpa/attachments/20080111/f2c5acca/attachment-0001.html