openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <>
Subject Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback
Date Tue, 24 Jul 2007 18:58:10 GMT

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.)


On 7/24/07, Roytman, Alex <> 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

View raw message