| Persistence context lost after rollback [message #389735] |
Thu, 25 June 2009 05:09  |
Eclipse User |
|
|
|
Hi All!
I have the following code:
try {
entityManager1.getTransaction().begin();
for (OItem i : itemList) {
entityManager1.persist(i);
}
for (OItem i : toBeDeletedList) {
entityManager1.remove(i);
}
entityManager1.getTransaction().commit();
} catch (javax.persistence.RollbackException ex) {
tetelList.addAll(toBeDeletedList);
} finally {
} finally {
toBeDeletedList = new LinkedList<OItem>();
}
There are two entities (Offer and OItem) in relationship with each other.
The above code is part of the Tetel management service. When the user
deletes a Tetel object the object is removed from the Item list and added
to the toBeDeleted list. If the user hits the save button the above code
runs.
The problem is, if any OItem in the toBeDeleted list is related to an
Offer allready, a persistence exception is thrown. I assume, that in this
case the transaction is rolled back, and the original state is restored,
however after the exception all OItems in the itemList become detached.
Is this the normal behaviour of eclipselink or I am missing something?
I am using eclipselink 1.0.1
Greets,
Gábor
|
|
|
|
|
|
|
|
| Re: Persistence context lost after rollback [message #389792 is a reply to message #389790] |
Mon, 06 July 2009 11:52  |
| Eclipse User |
|
|
|
> Could you explain this a bit detailed?
The extended EM keeps a list of every merge, removed or persisted entity. Then upon commit it simply loops over the actions and re-executes them. So it will actually do a "em.persist(e)". Eclipselink will make in memory copies and try to persist those. If that fails, you get an exception and then usually the administration of the entities is out of sync; e.g. some of the entities may already have a new versionnr assigned. Now, if you make changes to these entities and then attempt to persist them again, that will fail. However, the original entities, registered by the extended EM, have not been changed. Therefor you can simply make the change and call commit again. Which the will do the "em.persist(e)" again and an new attempt is made.
I've been using this in production for almost a year now. Works flawlessly.
Tom
|
|
|
Powered by
FUDForum. Page generated in 0.05533 seconds
Home