Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (herse.apache.org: domain of plinskey@gmail.com designates
 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=b+4CU1TeSdNOcdq6iWIHlxAw8YUo63GT2GokD3iO2b65thvx1oNbD1rVKc0O8el3i2t4WcNTVSgVqtw1ysiNhnSgop7WN/epVe6OE04RI5XIyfWzbAlLa/pEE+bcEoZithEVOPJ3DjR+QM0rSyaIUR/V2SeRP7A+JWP/RLUOupM=
Message-ID: <7262f25e0707241158m5f5508a5wa10022211a72afe9@mail.gmail.com>
Date: Tue, 24 Jul 2007 11:58:10 -0700
From: "Patrick Linskey" <plinskey@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with
 FatalDataStoreException forcing transaction rollback
In-Reply-To: <49BF64BA795F6A498EC2F04F39BAA8D3012878C3@ptint5.peacetech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <11442200.1182816385855.JavaMail.jira@brutus>
	 <5417680.1185294631049.JavaMail.jira@brutus>
	 <49BF64BA795F6A498EC2F04F39BAA8D3012878C3@ptint5.peacetech.com>

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 <Roytmana@peacetech.com> 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