openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Prud'hommeaux (JIRA)" <>
Subject [jira] Updated: (OPENJPA-166) Track the reason why a setRollbackOnly invocation was made
Date Fri, 09 Mar 2007 22:47:09 GMT


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

View raw message