Hi Kevin, We're good. You've closed the issue. I'm completely satisfied.
Craig On Sep 4, 2007, at 6:22 AM, Kevin Sutter (JIRA) wrote:
[ https://issues.apache.org/jira/browse/OPENJPA-343? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12524717 ]Kevin Sutter commented on OPENJPA-343: --------------------------------------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.I agree. We are performing this "afterCompletion" processing as far as we can until we hit this unexpected exception. This exception is now being logged (if trace is turned on) and the exception is returned to the caller. Unless you are suggesting that we should possibly log-and-eat this exception and attempt to continue additional processing as if nothing has happened, I think we have done everything we can do. If we went this log-and-eat route, it would require more more granular try-catch blocks in this path. Not sure this is necessary processing for the unexpected (rare) case.FYI, we are still flowing through the EntityManager with the setRollbackOnly invocation. So, any processing in the EntityManager and/or Broker that would be triggered because of the setRollbackOnly call will still happen. It's just the explicit setRollbackOnly call on the Transaction object itself that was conditionally skipped if the Transaction was not "active". Just wanted to clarify that aspect of the change.If there are still concerns about the general exception processing in the OpenJPA code base, then maybe we should open a separate JIRA issue or at least start a [DISCUSSION] topic on our dev mailing list. The original intent of this Issue was to not call the setRollbackOnly method when the Transaction is not in a state to accept the invocation. I think that issue has been resolved. But, maybe there are still concerns about the general exception processing within OpenJPA...Thanks, KevinDo not call setRollbackOnly on inactive Transactions ---------------------------------------------------- Key: OPENJPA-343URL: https://issues.apache.org/jira/browse/ OPENJPA-343Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.7, 1.0.0 Reporter: Kevin Sutter Assignee: Kevin SutterWhile 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 theexception 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 toget 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.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
