Description Tom Eugelink 2008-12-20 02:25:22 EST

Created attachment 120991 [details]
sources

Build ID: 1.0.2

Steps To Reproduce:
In a 3-tier application Eclipselink is usually used in a burst mode; transaction is started, a bunch of changes are made and stuff is either committed or rollbacked.

In a 2-tier application changes are made directly against the BM, but you would not want these changes to be written to the database immediately, because that would cause all kinds of locking issues.

So in practice this means that in a 2-tier application all changes are made outside a transaction. Entities are persisted, removed, changed and what have you. Then, when the used presses some save button, all changes must be persisted. For this it is required that the EM remembers all removed and persisted entities. 

However. If a transaction is started, and some entities have been persisted, something may go wrong. The database transaction is rolled back, but -and here is the pinch- any already persisted entities will have their version property set to the value that was assigned (incremented) during the persist. 

Now, when the error has been corrected, and the EM is repersisting, it will fail over the fact that the version number is incorrect.

In order to remedy that situation, you have to clear the EM. But that also clears the list of to-be-persisted and to-be-removed entities. Not good.

So I wrote two extentions to the entity manager and transaction that will remember these two lists. Naturally there are times when you really want to clear all, so I introduced the "executeNextClearWithoutClearingRemovedEntities" method where I abuse a lock to pass that information.

Anyhow. I'll add the two source.

More information: