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 it. 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 Alex -----Original Message----- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 2:58 PM To: [email protected] Subject: Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback 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
