オブジェクトとリレーションの狭間...

というのは、今少しややこしい対応をしているんです。

それはですね、最初はこういうことでした...

申請された内容が、まだ他人から承認されていないのならば、申請者によって取り下げができるようにして欲しい....

まあ、やりたいことは判ります。けども、

「承認アクション」と「取り下げアクション」がもし競合したらどうしよう？

という問題、おそらく「取り下げができるようにしてね！」と依頼した依頼元は想像してないであろう問題が発生するわけです....ここらへん、川上と実装者の感覚の違いなのですがけどもねぇ、実装者としては「少し工数かかります...」と答えざるを得ないわけです。

で、現実的にはそれぞれのアクションの中での、ＤＢ周りの処理では、Spring+Hibernate なので、サービス単位でトランザクションが管理されるようになっていて、

トランザクションがかかっている単位（サービス）の中は、アトミックと見ていい

ことになるから、サービスの中で「他の利用者による更新が競合しているか？」について TestAndSet をする格好になるでしょうか。

しかし、ここで、Hibernate がＯ／Ｒマッピングだ、という事実がすこし邪魔になります....現実問題として、Hibernate がキャッシュを使って「キーが同じなら、インスタンスが同じ！」という仮定で動くことが、困るんですね。「テスト」ができないんです。

言い換えると、「渡されたインスタンスと同じキーを持つデータが、渡されたインスタンス以降に更新されたものかどうかをチェックする」わけですから、「同じキー」で時系列的に後のデータがあるかどうか？というチェックがしたいわけです...しかし、Hibernate は「同じキーなら同じインスタンス」と捉えてしますのです。これ、考えてみれば、

オブジェクトとリレーションの間の裂け目

にしたいことが転がり落ちちゃった....ということにでもなるでしょうか？

まあ、チェック側を HQL ではなくて、SQL 直でやれば、こっそり「今のデータ」を取ることができて、TestAndSet ができたわけですが、何となく釈然とはしないですね。そもそも

リレーションはオブジェクトではない！

という事実から目をそらすための一時しのぎ...なのかも。オブジェクトデータベースならこういうの問題にならない...かもしれません。