I've got a big application which uses @version tags for the optimistic locking.
The thing i'm getting is that in transaction1 a version gets incremented. - This is also done in the db - This returns correctly if i do a entityManager.find - This returns correctly if i do a entityManager.createQuery with simple eql.
But in transaction2, the version is set back when i retrieve the object from the enitity manager (still correct in the database though).
At first i suspected a rollback, that seemed most logical, but it doesnt appear so, since some weird things get me to retrieve the correct version as well.
Let me explain with some pseudo code.
I think i'm doing something else wrong, but the refresh is the only (non-hardcoded) way of getting the real version of the child in the entityManager.
It appears that my parent is in the enitity manager with a old version of child. And when the parent is retrieved, it's old reference of child overwrites the updated (post-transaction1) version of child?
Am i supposed to use refresh, or is something else going wrong?
Jesse van Houten [ August 21, 2008: Message edited by: Jesse van Houten ]
It sounds like transaction 1 is not committed when transaction 2 is executed (since its throwing an optimistic locking error), have you tried forcing the commit in transaction 1?
Also keep in mind many EJB/J2EE server implementations are beta-ish and filled with unfixed bugs, what software are you using? You might want to consider taking a look at the source code for the server (if its available) to understand what's going on behind the scenes.