openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-343) Do not call setRollbackOnly on inactive Transactions
Date Fri, 31 Aug 2007 02:42:30 GMT


Kevin Sutter commented on OPENJPA-343:

> I guess the issue is whether this is a trace scenario or a more serious problem that
should be reported back. We are still in commit as far as the application is concerned and
it's not obvious to me that this is a successful transaction. I'd think we should cause the
outer level transaction to fail with a SystemException because the application handling is
not consistent (the cache, for example, might be in an inconsistent state). If the application
thinks everything is aok, then I think we have a problem. 

When we get to this spot, the Transaction is complete.  All of the prepares and commits and/or
rollbacks have completed.  The afterCompletion call is just a convenience callback to let
those resources that have registered for Synchronization that the transaction has completed.
 The parameter on afterCompletion lets you know whether the transaction committed or rolled
back.  So, there is nothing to "fail".  

And, actually, the IllegalStateException that I mentioned about we get when we attempt to
call setRollbackOnly is only logged by the TM.  It is not thrown back to the caller since
there is nothing to fail.  So, the application actually continues running without a problem.
 The exception just gets logged so that we know that something isn't quite right, but everything
still completed "okay".

> Do not call setRollbackOnly on inactive Transactions
> ----------------------------------------------------
>                 Key: OPENJPA-343
>                 URL:
>             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
> 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.

View raw message