[jira] Commented: (OPENJPA-343) Do not call setRollbackOnly on inactive Transactions

["Kevin Sutter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENJPA-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523962 ] 

Kevin Sutter commented on OPENJPA-343:
--------------------------------------

I should clarify a couple of statements.  I mixed Transaction and Synchronization concepts in the above description.  Since we are in the afterCompletion (Synchronization) processing, the Transaction is in a "completed" state and can no longer accept the setRollbackOnly invocation.  Although related, Transaction and Synchronization are two separate concepts and should treated as such.

I plan to resolve issue (1) by checking for a valid transaction status before calling setRollbackOnly.  If the transaction is not in a suitable state, I will log a trace message indicating that the setRollbackOnly can not be called, but processing will continue.

Re-looking at the code, I think we are already sufficiently addressing items (2) and (3), once issue (1) is resolved.  We already have the necessary trace logging for this unexpected exception.  Granted, we didn't expect this exception and it's a "pain" to turn on trace for long-running scenarios, the real exception that caused the problem in the first place will now get logged due to the fix for (1).  And, since OpenJPA doesn't have the concept of a first-failure-data-capture logging facility, it would get cumbersome to log every unexpected exception.

So, my plans at this point are to just resolve the first issue (1) with ensuring that we do not attempt to call setRollbackOnly when the transaction can not accept it.  Comments welcome.

Kevin

> Do not call setRollbackOnly on inactive Transactions
> ----------------------------------------------------
>
>                 Key: OPENJPA-343
>                 URL: https://issues.apache.org/jira/browse/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.