[
https://issues.apache.org/jira/browse/OPENJPA-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523976
]
Craig Russell commented on OPENJPA-343:
---------------------------------------
I agree that 1) not calling setRollbackOnly during afterCompletion is correct.
But when 2) an unexpected exception occurs during afterCompletion, like a
NullPointerException, it seems that we should log the exception. Even though
it's during afterCompletion, we shouldn't just swallow it. Of course, fixing 1)
means that 2) can't be reliably reproduced.
I'm not clear on what 3) means.
> 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.
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.
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.
