Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] Question about entity manager flush() and exceptions

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



Back to the top