Re: [eclipselink-users] IndirectSet/IndirectList relationship may cause

[James Sutherland <jamesssss@xxxxxxxxx>]

When you persist a new object it should not be referring to any detached
objects, or any objects from any other persistence contexts.  This will
corrupt the persistence context.  New objects should only reference managed
objects or other new objects with cascade persist.  If you have references
to detached objects you should use merge() not persist.  Or use find() or
getReference() to get the version of the detached object from the current
persistence context.

I'm not sure why it is accessing the C relationship, my guess is that it
think the B object is new, so is trying to persist it.  You can set the
persistence unit property "eclipselink.validate-existence"="true" to have
persist first check the database to see if an object existing before
persisting it (but not persisting corrupt objects would be better).

In general EclipseLink supports accessing LAZY relationships after the
persistence context has been closed.  It does this using its
non-transactional read connection pool.


Patric Rufflar wrote:
> 
> Hi,
> 
> I am seeing a strange EclipseLink (2.3.2) behavior:
> 
> Imagine an entity class A which refers to an entity class B via 
> OneToMany(cascade=PERSIST) relationship which itself refers to entity 
> class C via ManyToOne(cascade=PERSIST) relationship.
> 
> Furthermore imagine the following steps:
> 
> 1. find() entity B with entity manager 1 (which contains references to 
> at least one entity C)
> 2. Detach this entity from entity manager 1 (optional step)
> 3. create a new instance of A
> 4. set a reference from A to the detached B
> 5. Persist A on entity manager 2
> 
> When tracing through the operations which EclipseLink does on 
> persist(), the resolving of the relationship B->C which is done by 
> IndirectSet.buildDelegate() seems to re-use the Session/UnitOfWork from 
> entity manager 1!
> In the best case this will lead to some exceptions (e.g. the connection 
> from entity manager 1 has already been closed before), but in the worst 
> this will silently lead to strange dirty read/data inconsistency 
> situations.
> 
> At least with the optional step 2, the detachment, I would never expect 
> that such an entity is still silently referencing and using the entity 
> manager on which it was previously attached.
> But even without the detachment this would be very questionable.
> I thought that (at least detached) entities can be considered as simple 
> beans and do not have any restrictions regarding share/re-usage.
> 
> Is this behavior expected?
> 
> (Related: 
> http://stackoverflow.com/questions/11398527/jpa-entity-sharing-among-different-entity-managers 
> )
> 
> Thank you and best regards,
> Patric
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.eclipse.org/forums/index.php?t=thread&frm_id=111&S=1b00bfd151289b297688823a00683aca
EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/IndirectSet-IndirectList-relationship-may-cause-transaction-session-mix-up-tp34135133p34151387.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.