バックエンドアプリケーションがありますが、アプリケーションにユーザーインターフェイスがありません。アクションは、サーバーがUDPおよびTCPポートでリッスンする着信データによってトリガーされます。
Customerテーブルがあり、テーブルには15個のフィールドがあります。各フィールドは、いくつかの重要な詳細または他の情報へのポインタを表します。例えば、
CUSTOMER_TABLE {
ID,
NAME,
DEFAULT_ADDRESS_ID,
EMAIL_ADDRESS,
LAST_LOGIN,
VERSION <--- trying to introduce
}
IDを除いて、これらの各フィールドは、一度に異なるプロセスによって更新できます。2つの並行プロセスが互いの値をオーバーライドするときに問題が発生します。そこで、私はVERSIONを導入しました-休止状態で生成されたバージョンフィールド。
ここで、時間T1でServer1がバージョン#400の顧客モデルを取得するとします。時間T1でバージョン#400の顧客モデルを取得するServer2
Server1はEMAIL_ADDRESSを変更し、CUSTOMERを更新します(T2で)。したがって、新しいバージョン番号は401(休止状態で生成)です。
Server2はNAMEを変更し、T3でCUSTOMERを更新しようとします。バージョン番号は、DBのバージョン番号よりも古いため、トランザクションは失敗します。
このアプリケーションは非ユーザーインターフェイスアプリであるため、ユーザーに変更の承認を求めることはできません...変更が反映されるように適切に処理する必要があります。
この種の状況に対処するために必要なすべてのオプションは何ですか?
アプリは以下の構造を持っています
Listening Port Handler -> Service Wrapped in Transaction -> DAO -> DB
そして次のアプリについては-ここに免責事項があります-これは悪いデザインだと私は知っています...しかし残念ながら、アプリは非常に計画外の方法で非トランザクションアプリからトランザクションアプリに進化しました...そして私はしません全体的な設計を修正する「時期」を決定する上で、多くの制御が可能です。今構造...。
Listening Port Handler -> Service invoked to get the model(ModelX) -> DAO -> DB (yes you are right, the model goes out of transaction boundary ... :-( )
-> Invoke different independent operations, each operation wrapped in txn -> DAO -> DB
-> Modify Model (ModelX)
-> Update model(ModelX) as a separate transaction -> DAO -> DB
2番目の問題で問題が発生します。モデルを更新できません。更新すると、モデルで変更されたものがすべて失われるか、すべての手順を再度繰り返す必要があり、他の操作が成功する可能性があります。 (少なくとも)2回発砲
私の質問は-とにかくそれはありますか
- hibernateは変更された属性を理解できます
- バージョンを確認する
- 手元のバージョンが古くなっている場合は、新しいバージョンを入手して、新しいバージョンに変更を適用します
- オブジェクトを保存します(例外をスローする代わりに)