|
|
| Re: not persisted values are lost when cloning [message #758053 is a reply to message #758008] |
Mon, 21 November 2011 20:11   |
|
The source is the clone, the two are normally different. There is one exception, when the original is the clone when you read an object directly into the UnitOfWork/EntityManager. In this case the shared cache is not used, so there is no original, this occurs after a flush has occurred, because the shared cache may be out of date, so it no longer used.
If you use a CloneCopyPolicy (default normally when weaving and using field access), the clone is used, so the transients are carried over. But again, if reading after a flush there will be no original, so a new instance would be used.
James : Wiki : Book : Blog : Twitter
|
|
|
| Re: not persisted values are lost when cloning [message #758262 is a reply to message #758053] |
Tue, 22 November 2011 13:28 |
 Tom Eugelink
Messages: 817
Registered: July 2009 |
Senior Member |
|
|
On 21-11-2011 21:11, James wrote:
> The source is the clone, the two are normally different. There is one exception, when the original is the clone when you read an object directly into the UnitOfWork/EntityManager. In this case the shared cache is not used, so there is no original, this occurs after a flush has occurred, because the shared cache may be out of date, so it no longer used.
>
> If you use a CloneCopyPolicy (default normally when weaving and using field access), the clone is used, so the transients are carried over. But again, if reading after a flush there will be no original, so a new instance would be used.
Ok. I figured out what went wrong.
By now you guys may know that I keep a list of modified objects in my fat Swing application (basically I record the EM interaction) and when the user presses the save button, start a transaction, and then persist / merge / delete all the changes (play the recording, so to speak).
This is done so that when there are problems (e.g. database constraints complaining), the user can make a change and the application can resubmit all the modifications.
In order to make this work, I have to clear the EM prior to saving, so any leftovers from a previous save attempt (most notably: incremented version values) are discarded.
This has been working very acceptably for years, giving the fat client an expected behavior.
What happens in this specific scenario is that the sellorderline needs to create additional entities (aka allocate from the stock) and that must be done inside a database transaction because pessimistic locking is used to prevent double bookings. (This is a legacy approach that must be confirmed to.)
So the user sets the transient amount and presses save, the EM is cleared, a transaction is started and the entities are persisted (in this scenario nothing is persisted since the amount is transient).
After this, but still inside the the transaction, the allocation logic is called and it tells sellorder to lazy load the collection of sellorderlines.
This collection apparently has been cleared prior to the save and thus is reloaded from the database (with each sellorderline having a null amount), the modified sellorderline is not in the collection.
The allocation logic then iterates over that collection and never sees the modified sellorderline.
Every solution has it problems. Now to figuring out a fix.
Tom
|
|
|
Powered by
FUDForum. Page generated in 0.03467 seconds
] 
Search
Help
Register
Login
Home
