openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roytman, Alex" <>
Subject RE: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback
Date Tue, 24 Jul 2007 20:24:33 GMT
Hello Patrick,

Thank you for your reply. 

Could you guys at least help me to convince BEA support that this
behavior is not in compliance with specs? As it is they keep saying it
works per specs and refuse to do anything. 

Aren't you and Neelan still Kodo program/tech managers?

An email from you should be sufficient. 

Unfortunately the specs are not crystal clear in this respect. It does
say about making exception fatal on when an exception happens on flush()
but they say nothing specific about recognized types of exceptions which
should behave per specs. That is why we need an expert opinion here.

Whatever specs say or do not say, I believe it is a very serious
deficiency killing huge class of absolutely necessary functionality.

We need to release a new version of our old application in couple of
months. It was developed before this exception re-wrap has been
introduced and have extremely heavy consistency validation logic
happening in jdoPerStore() now it is all broken because of the rollback.

This should be a trivial fix. Just introduce another config param
whether to wrap or not and inspect an exception class before wrapping

The trouble is that all the expertise and core developers seem to be in
this OpenJPA group while official BEA support appears to be just
figureheads. As a maintenance paying customer I am very upset with it.

On the other note, do you think JPA will reach level of JDO 2.0 services
in the near future?

Thanks again


-----Original Message-----
From: Patrick Linskey [] 
Sent: Tuesday, July 24, 2007 2:58 PM
Subject: Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with
FatalDataStoreException forcing transaction rollback


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