| Hi Jörg,
It's fair to request clarification of the behavior if it is not clear.
The reason to fail commit is for separation of concerns in the application. If the user is in the part of code that knows how to recover from a flush failure, the flush() api should do the trick. That api is documented not to roll back the transaction, so refresh of conflicting instances is possible and still save the transaction.
Craig On Nov 2, 2006, at 8:12 AM, Jörg von Frantzius wrote: Alright, I just saw that JPA spec says in "5.5.2.1 The EntityTransaction Interface":
If the EntityTransaction.commit operation fails, the persistence provider must roll back the transaction.
So I take back my proposal in order to align with JPA.
Regards,
Jörg
Jörg von Frantzius schrieb: Dear experts,
after looking at the spec, and 13.4.4 "Non-managed environment" in particular, I'm somewhat puzzled about what the expected behaviour of javax.jdo.Transaction.commit() should be upon encountering an exception during flush. What JPOX currently does is an automatic rollback of the DB connection and of the PM's caches, calling sync.afterCompletion(Status.STATUS_ROLLEDBACK) and setting the state of the transaction to not-active. I wonder whether that's really intended.
While there isn't much a user can do about an optimistic failure during flush, there could be any SQLException happening during flush that the user might want to catch and try to recover from, I imagine. He won't be able to do so if the transaction is automatically rolled-back.
So my proposal would be that upon failure during flush, nothing should be done by the implementation but throwing the appropriate exception.
Regards,
Jörg
<joerg.von.frantzius.vcf> |
smime.p7s
Description: S/MIME cryptographic signature
