[news.eclipse.rt.eclipselink] Re: in memory rollback

[tbee <tbee@xxxxxxxx>]

> I would vote for your solution where the transfer is committed first in 
> its own transaction with booked=false. That makes sure the must have 
> operation is written and cannot be lost.

Yes. Well. That works kinda acceptable when a new entity is created, but when the entity already exists, and is changed, this is no good.

If a new entity is created, you end up with an entity marked as "dirty" but no allocations, that is acceptable. But when an entity is changed, the old allocations are not changed. So you end up with an inconsistent situation. What when the user then decides to navigate away? So I really really want to commit all or nothing.

By retrying during save I can prevent this as a result of a change. The problem was with removing. By using my application level duringDeletePreRemove event I can force all to-be-removed entities to set the values to zero, thus causing the allocations to be removed and validated. This may fail, but since it is BEFORE remove, that works out well so far.

This approach needs a shake down in real life.

Tom