I'm noticing that updates are not incrementing versions on the objects being updated until after transaction completion - so logic during the transaction after the .update() call don't get the to-be version count.
In our case we have some integrated workflow, and we're creating changelog digests with reference to the previous entity, and as the version counters don't increment until the final tx completes (we use spring @Transactional) the compares contain the same version number as previous.
The update works perfectly if i take away the @Transactional & do each in new transactions, but i think this is highlighting a change that the object (and child objects participating in the tx too) are not consistent thoughout the tx.
I can't update to 3.6 or 4 to check this yet, but prev to 3.5.6 we were able to manually adjust the value prior to submit to the createWorkflow() and then set it back after - in 3.5.6 this causes the version counter to increment by 2 after tx completion.
3.5.6-Final, Oracle 10/11G
linux and windows sun java 6 1.6.0_24
In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.
If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.
Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!