0

私はアプリを継承しました。このアプリは、トリガーベースの挿入と更新を行い、StaleObjectExceptionをスローすることがあります。多くのデバッグ（tx、hibernate、typeなど）を追加しようとしたため、さらに混乱しました。

15:21:00 Calling dao.insert
15:21:00 starting Trancation T1 
15:21:01 insert records including object #290595
15:21:01 Transaction T1 commits

ログ、休止状態の挿入、およびデータにtx commitが表示され、実際、ID＃290595のオブジェクトが値としてバインドされています。15:24:00にも同様の挿入がありますが、15：25:00まで、アプリは完全にサイレントです（ユーザーなし、その他のアクティビティなし）。

15:25:00 Start a Required_new transaction T2
15:25:00 Calling dao.finder
15:25:01 dao transaction uses propagated T2
15:25:01 Select returns object with id #290595
15:25:01 ends propagated transacted finder
15:25:02 calling dao.update
15:25:02 dao transaction uses propagated T2
15:25:02 binds object with id #290595
15:25:02 Could Not Synchronize Database State With Session (StaleObjectStateException)

データベースのSQLクエリは、レコード＃290595が実際には存在しないことを示しています。挿入から失敗まで4分あります。言うまでもなく、それは通常、ほとんどの日で機能しますが、突然....

トランザクションコミット時に休止状態が自動的にフラッシュしてコミットしませんか？

挿入によってデータがキャッシュに移動されたが、DBには移動されなかったと仮定します。これはキャッシュに再び見つかりましたが、DBにないため、更新を拒否します。だから問題は本当に誰かが素晴らしいアイデアを持っているかどうかです？

これはOracleDBであり、T2にRequired_newトランザクションがあり、isolation_levelがシリアル化されていることを確認しようとしましたが、ほとんど効果がありません。挿入が何らかの形でコミットされていないままになっていると思い始めています。

どんな提案も歓迎します

4

1 に答える 1

0

さて、私は自分で答えを見つけました。

Hibernatever2でStaleObjectStateExceptionのjavadocに出くわしました。

Thrown when a version number or timestamp check failed, indicating that the Session 
contained stale data (when using long transactions with versioning). Also occurs
if we try delete or update a row that does not exist.

私は常に2番目を想定し、最初のバージョンを見ることはありませんでした。バージョンは確かにタイムスタンプでした。この記事も読んだ後、バージョン属性を長く変更し、すぐにすべてのエラーがなくなりました。不一致についてはわかりませんが、アプリケーションロジックに違いはありませんでした。

とにかくバージョン管理にタイムスタンプを使用したいのはなぜですか？

于 2013-03-19T07:57:05.207 に答える