Re: [eclipselink-users] Question about entity manager flush() and except

[James Sutherland <jamesssss@xxxxxxxxx>]

Can you include your code?

I'm not sure how you are retrying after the error, but this is probably the
cause.

In general in JPA, retry is not allowed, if an error occurs the persistence
context is set to rollback only mode, any managed object may be in an
inconsistent state.  Normally you are required to create a new persistence
context, or call clear before any further operations.

If you are merging the partially committed objects into a new EntityManager,
then be careful to reset their generated ids, as these were assigned in a
transaction that may have been rolled back.


NBW wrote:
> 
> 
> Hi folks,
> 
> I'm debugging some interesting problems which I think revolve around the
> behavior of flush(). I'd like to get some expert feedback on what I am
> seeing. 
> 
> I have two entities.  EntityA with a sequence table generated id and
> EntityB with a sequence table generated id and a @ManyToOne relationship
> (using a join column) to EntityA.
> 
> I'm dealing with one transaction which creates EntityA, then it goes
> through a process of instantiating and persisting a bunch of EntityBs in a
> loop.  The loop is wrapped in a try/catch block to facilitate retrying the
> process (don't ask...).
> 
> At some point during the persisting of EntityBs (maybe after the first or
> maybe after some number, I am not sure) it seems a flush() is triggered
> and the statements flushed include EntityA's persist and some number of
> EntityB persists.  This flush is triggering a SQL exception related to
> some bad data in EntityB. 
> 
> The SQL exception is caught by the aforementioned try/catch and the retry
> logic causes the process of instantiating and persisting to be
> repeated/retried. 
> 
> On the second go around the flush is again triggered, however, in addition
> to the SQL exception related to EntityBs bad data there is also a
> constraint violation on EntityA. The constraint violation indicates that
> its primary key is not unique anymore. 
> 
> This behavior is repeated until the max retry count is hit and we throw an
> exception to the caller which eventually rolls back the TX.
> 
> Based on what I am seeing it seems to me that during the first flush()
> EntityA is successfully created and its ID is set, however, on subsequent
> flushes() the EnityManager is trying to recreate EntityA again and hence
> the unique constraint violations.  This is surprising. I would have
> thought that the EntityManager would know that EntityA was created already
> (due to the first flush()) that it should not need to try to persist
> EntityA again.  Would having the catch block explicitly call .clear() fix
> the unique constraint violation and would EntityA's reference retain the
> state that was the result of the first flush() even after calling
> .clear()?
> 
> Thoughts?
> 
> Thanks,
> 
> -Noah
> 
> 


-----
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/Question-about-entity-manager-flush%28%29-and-exceptions-tp34007490p34012625.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.