Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » not persisted values are lost when cloning
not persisted values are lost when cloning [message #758002] Thu, 17 November 2011 16:16 Go to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 807
Registered: July 2009
Senior Member
I have a entity that has a value that is only kept in memory. But when EclipseLink clones the entity, that value is not copied over. Is there any way (a post clone event) to add that to the clone?
Re: not persisted values are lost when cloning [message #758008 is a reply to message #758002] Mon, 21 November 2011 09:21 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 807
Registered: July 2009
Senior Member
Funny thing is that if I look in the

public void postClone(DescriptorEvent descriptorEvent)

The descriptorEvent has the same object for both originalObject and source. It would expect to have the original and the cloned object availabe in this event.

Tom
Re: not persisted values are lost when cloning [message #758053 is a reply to message #758008] Mon, 21 November 2011 20:11 Go to previous messageGo to next message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

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 Go to previous message
Tom Eugelink is currently offline Tom Eugelink
Messages: 807
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
Previous Topic:Re: Descriptor Events on Entities which have not been modified during a Transaction
Next Topic:Re: PerformanceMonitor in Standalone or OSGI environment?
Goto Forum:
  


Current Time: Thu Sep 18 17:54:49 GMT 2014

Powered by FUDForum. Page generated in 0.48628 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software