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