[
https://issues.apache.org/jira/browse/OPENJPA-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux updated OPENJPA-166:
---------------------------------------
Attachment: OPENJPA-166.patch
Attached is a patch that adds a Throwable argument to all the setRollbackOnly()
invocations, tracks it in the LocalManagedRuntime and reports on the cause is a
commit() is attempted. Also attached is integration with the WLS Transaction's
setRollbackOnly(Throwable) method.
> Track the reason why a setRollbackOnly invocation was made
> ----------------------------------------------------------
>
> Key: OPENJPA-166
> URL: https://issues.apache.org/jira/browse/OPENJPA-166
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Affects Versions: 0.9.0, 0.9.6
> Reporter: Marc Prud'hommeaux
> Priority: Minor
> Attachments: OPENJPA-166.patch
>
>
> Currently, when setRollbackOnly is invoked on a Broker or EntityManager,
> there is no way to specify the cause or reason for the invocation. Given that
> we invoke setRollbackOnly() whenever most PersistenceExceptions are thrown
> (in org.apache.openjpa.persistence.PersistenceExceptions as per section 3.7
> of the JPA spec), transactions are frequently marked as RollbackOnly when
> problems occur. If one part of an application swallows or otherwise handles
> the exception, and another part of the application tries to subsequently
> commit the transaction, it has no way of having any idea what caused the
> problem. And even though the RollbackOnly flag can't be reset, it can be
> useful for reporting purposes, or for application logic outside of the
> transaction to know whether to re-try the entire operation.
> Furthermore, this behavior can cause problems with managed JTA transactions,
> since if an exception occurs during the flush or commit process (e.g., if a
> duplicate primary key is persisted), the rollback only flag gets set on the
> JTA transaction. Some TransactionManagers will check this flag at various
> points in the commit process and eagerly fail when they see the RollbackOnly
> flag, leaving the developer of the managed application with no way of knowing
> what caused the transaction to fail.
> I propose to add a new setRollbackOnly(Throwable cause) method to Broker and
> EntityManager, where we can internally track the cause of the invocation. If
> nothing else, then the application programmer can at least access it with a
> getRollbackReason() method and act accordingly. Also, some TransactionManager
> implementations (such as BEA's, which exhibits the behavior I described
> earlier) have their own extensions for tracking the rollback reason, and we
> might be able to integrate with them by sharing this knowledge.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
