openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [jira] Commented: (OPENJPA-343) Do not call setRollbackOnly on inactive Transactions
Date Tue, 04 Sep 2007 15:05:15 GMT
Hi Kevin,

We're good. You've closed the issue. I'm completely satisfied.


On Sep 4, 2007, at 6:22 AM, Kevin Sutter (JIRA) wrote:

>     [ 
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
> tabpanel#action_12524717 ]
> Kevin Sutter commented on OPENJPA-343:
> --------------------------------------
>> Here's where we might disagree. The user-level commit should fail  
>> so the user doesn't think everything is ok as far as the cache is  
>> concerned. I understand that the database transaction is complete  
>> and whatever changes have been made there are permanent. But the  
>> EntityManager is possibly corrupted.
> I agree.  We are performing this "afterCompletion" processing as  
> far as we can until we hit this unexpected exception.  This  
> exception is now being logged (if trace is turned on) and the  
> exception is returned to the caller.  Unless you are suggesting  
> that we should possibly log-and-eat this exception and attempt to  
> continue additional processing as if nothing has happened, I think  
> we have done everything we can do.  If we went this log-and-eat  
> route, it would require more more granular try-catch blocks in this  
> path.  Not sure this is necessary processing for the unexpected  
> (rare) case.
> FYI, we are still flowing through the EntityManager with the  
> setRollbackOnly invocation.  So, any processing in the  
> EntityManager and/or Broker that would be triggered because of the  
> setRollbackOnly call will still happen.  It's just the explicit  
> setRollbackOnly call on the Transaction object itself that was  
> conditionally skipped if the Transaction was not "active".  Just  
> wanted to clarify that aspect of the change.
> If there are still concerns about the general exception processing  
> in the OpenJPA code base, then maybe we should open a separate JIRA  
> issue or at least start a [DISCUSSION] topic on our dev mailing  
> list.  The original intent of this Issue was to not call the  
> setRollbackOnly method when the Transaction is not in a state to  
> accept the invocation.  I think that issue has been resolved.  But,  
> maybe there are still concerns about the general exception  
> processing within OpenJPA...
> Thanks,
> Kevin
>> Do not call setRollbackOnly on inactive Transactions
>> ----------------------------------------------------
>>                 Key: OPENJPA-343
>>                 URL: 
>> OPENJPA-343
>>             Project: OpenJPA
>>          Issue Type: Bug
>>          Components: kernel
>>    Affects Versions: 0.9.7, 1.0.0
>>            Reporter: Kevin Sutter
>>            Assignee: Kevin Sutter
>> While in the middle of processing an afterCompletion invocation in  
>> BrokerImpl, an unexpected RuntimeException  
>> (IndexOutOfBoundsException) occurred within some underlying  
>> WebSphere code.  While we (OpenJPA) were attempting to clean up  
>> after that exception, we attempted to call setRollbackOnly on the  
>> current transaction.  But, since we were in the process of  
>> completing the current transaction, it is invalid to be calling  
>> setRollbackOnly and we ended up getting an IllegalStateException  
>> from the WebSphere Transaction Manager.  Due this second  
>> exception, we ended up losing track of the original exception and  
>> this became a difficult problem to diagnose.
>> This issue will be used to correct a couple of issues (at least):
>> 1)  We should ensure that the transaction is active before calling
>> setRollbackOnly().  When an exception happens during afterCompletion
>> processing, the Transaction can no longer accept setRollbackOnly
>> invocations.
>> 2)  When an unexpected exception happens like this, we should log the
>> exception before attempting to process the exception.  In this  
>> particular
>> case, we lost the original exception when we ran into the  
>> IllegalStateException
>> from the Transaction service.  This forced us to re-run the  
>> scenario just to
>> get a trace of the exception.
>> 3)  Or, if we don't want to log the exception immediately, we need  
>> to determine why we lost the first exception in the first place  
>> and ensure that doesn't happen again.
>> Kevin
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message