Hi, Sadly, nothing that happens in this community has any impact on Kodo 3. OpenJPA is only used in Kodo 4.1 and newer.
I believe that this behavior is different in Kodo 4.1 at least -- the fatal-ness of an exception is separate from its type now. It looks like in OpenJPA, we setRollbackOnly when any exception (including OpenJPA exceptions) happens during flush or attach operations. However, it looks like we do *not* do any rollback configuration if you call preFlush() directly. You might want to try calling KodoPersistenceManager.preFlush() to see if you can recover from that method invocation. (Everything above is based solely on code inspection, so take it with a grain of salt.) -Patrick On 7/24/07, Roytman, Alex <[EMAIL PROTECTED]> wrote:
Hello everyone, I noticed that at some point in Kodo 3.x its behavior changed. Now it catches any exception including JDOUserException thrown in jdoPreStore() and wraps it in FatalDataStoreException which forces transaction rollback and preventing further retry. JDOUserException is a retriable exception according to specs while FatalDataStoreException is not. This change of JDO exception type makes it completely impossible to retry JDOUserException thrown in jdoPreStore() since the transaction is automatically rolled back. It causes severe functionality loss as most of the model consistency can be only enforced on store (when all the changes have been done) and now any validation JDOUserException thrown in jdoPerStore() causes immediate rollback with no chance to fix the issue and recommit I struggled for a month with BEA official support but they do not even want (able to?) to look into it seriously and try to convince me that it functions as expected. I tried to reason that JDOUserException is defined as retriable but to no avail Thank you Alex
-- Patrick Linskey 202 669 5907
