Hello
I found few posts on the subject but they didn't really help, so I imagined I could ask once more - testing your patience :-)
Here goes my case:
From time to time, StaleObjectStateException gets thrown, indicating another user of my system modified something "behind the scenes". Of course, being prepared for this - I catch the exception and inform user of problems that occured. Sometimes user does not want to hear about all this and simply wants to save his work in 'no matter what' manner. This should be relatively simple to implement - was my first thought - but I've been having really hard time with this scenario. I will present little real code, because Hibernate is underneath my own DAO layer - this would be no help to other users, but here goes description of what I do:

1. reload from session conflicting object



2. rollback "old" transaction and close the session

3. reattach conflicting object from 1 with new session and force update

3. is my pain - I tried everything that, I believed, would work - tried to call session.merge - nope - another StaleObjectStateException, tried to call session.update - the same, tried to lock with LockMode.UPGRADE - guess what happened :-(. I simply want to force Hibernate to execute another update with old data and new version number, plain old simple overwite. How can I do this? What really works is scenario when user, informed about concurrentm odification wants to leave his work behind - then combination of refresh and merge works, enabling him to continue his work on new data. What is the recommended pattern of dealing with this kind of situation? Thank you in advance for your answers.

PS. I am using Hibernate 3.2.6 GA

Hello,
Workaround: after closing the session in which conflict occured, use

to retrieve modified object. Then retrieve its version property by introspection (I use commons-beanutils for that):



assign newVersion to old, conflicting object (more introspection)
and then merge


In my humble opinion it is far too more work for such a simple use case. Root of the problem lies in Hibernate checking whether version has changed during merge and throwing exception if it did. I think this is not what the purpose of merge is - version should be treated more like meta-property of object and not be subject of merge operation, version should be simply taken from persistent instance rather than from detached one. After all, merge is mainly used for updating persistence instance with detached one's values, so if developer uses it he is aware that changes might have been made to persistent instance, so version update and exception is almost certain. I came up with analogy to source control systems, wondering if you find it eligible: merge will not fail because of different values of "CheckedIn By" property, unfortunately that's what you are trying to force here - merge cannot be carried out if version properties differ. Taking my analogy further - it is like Source Control system allowing to merge iff you are merging against your own files (CheckedIn By). I don't care here about names really - maybe we, or I, be missing session method which performs the "real" merging task, but named differently - let's say - forceMerge?

Hi
I'm looking for the excact same behaviour. but as soon as i try this with a parent entity having a child collection Merge throws a StaleStateException if i also add/remove children concurrently. The child collection is mapped with a inverse bag with all-delete-orphan and only its parent has a version property.