I have an application running under GlassFish v2UR1, which occasionally deletes a row in a database table. Before this deletion, but in the same transaction, the row is updated for reasons of bookkeeping. And this update is in certain circumstances lost in the sense that TopLink does not even try to execute it (I turned logging for persistence to finest and never see the update statement, only the following delete statement).
To qualify "certain circumstances":
When I have a user transaction such as:
@Resource private UserTransaction utx;
...
utx.begin();
myObj.setDeletedBy("John Doe");
myObj = entityManager.merge(myObj);
entityManager.remove(myObj);
utx.commit();
Then everything works fine. The update is executed and subsequently the delete.
However, working with container-managed transactions the update is never executed, only the delete is. So my question is:
When does the container determine that an object is not to be updated and therefore a call to merge will simply be skipped? There may well be something wrong with my code, so if someone could tell me the circumstances under which GlassFish skips merges before removes, I might be able to find the bug in my code.
It is perhaps relevant to note that the entity class in question is using optimistic locking via a timestamp field.
Many thanks in advance for any pointers,
Ulrich
[Message sent by forum member 'ulim' (ulim)]
http://forums.java.net/jive/thread.jspa?messageID=256954