I've recently been added onto a very complicated project with heavy persistence. Hibernate was used from the start, although often incorrectly, and one of our new tasks is to provide transaction support across large units of work.

The resulting increase in session scope has caused numerous issues, frequent non-unique object exceptions, double encryption (as a result of an encryption interceptor that gets called on dirty flushes, but if the object is retrieved again later from session rather than the database, it is never decrypted, but encrypted again on the final flush during commit).

We have been painstakingly combing through these issues when they arise, but its inevitable that we will miss something on a project of this scope. I had an idea for a blanket approach to solve these problems, but I am eager to hear the consequences before implementing them.

The app has been functioning correctly before transaction support, I assume any hibernate issues that popped up were handled specifically under the assumption that saves and deletes were explicit and non-deferred. I would like to mimic that functionality by replacing all the calls to save with a merge/flush/evict combo. I am under the impression that the merge will save or update or merge and erase the non-unique object exceptions, and the flush evict will remove the double encryption problem.

Now that I think about it, the merge may be unnecessary if I simple use save/flush/evict for all calls. But regardless, I'd like to hear the potential consequences of such an approach, not so much regarding the performance but if actual functionality might be impacted. Is there any scenarios where this approach would prove to be flawed? Would we still maintain proper transaction support with the final commit at the end?