openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-343) Do not call setRollbackOnly on inactive Transactions
Date Sun, 02 Sep 2007 17:41:19 GMT

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

Craig Russell commented on OPENJPA-343:
---------------------------------------

> So, when an exception happens in this code path, it could mean that some of our cleanup
didn't complete. We do log any exceptions that happen during this path via trace statements
and the exception does get re-thrown.

> There is nothing we can do at this point to revert the state of that transaction. It
was already either committed or rolled back by the time the afterCompletion method is invoked.

I agree.

> The parameter on afterCompletion lets you know whether the transaction committed or rolled
back. So, there is nothing to "fail". 

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.

Craig

> 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.


Mime
View raw message