openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] Commented: (OPENJPA-102) JTA transaction rollback, nonexistant instances, transactional persistence context => failures during afterCompletion() and close()
Date Wed, 17 Jan 2007 19:38:30 GMT


Patrick Linskey commented on OPENJPA-102:

Actually my description in the prior comment is incorrect. The test case does the following:

1. EntityTransaction.begin()
2. getReference() on nonexistent record
3. rollback() in a business method
4. EntityManager.close(), which fails while running the detach algorithm

IOW, short-circuiting close() won't fix the problem, as close() has only been called once.
Additionally, on further inspection, EM.close() asserts that it's open before calling broker.close(),
so there will never be multiple close() invocations.

The problem does not occur in a JTA context, as the persistence context is coincident with
the JTA transaction in that scenario, not the lifecycle of the EntityManager.

It does not seem possible to disable the detach algorithm altogether. However, further investigation
indicates that this is probably happening because OpenJPA is not clearing the persistence
context during JPA rollback. From section 3.3.2 of the JPA spec:

"For both transaction-scoped and extended persistence contexts, transaction rollback causes
all pre-existing
managed instances and removed instances[15] to become detached. The instances' state will
be the
state of the instances at the point at which the transaction was rolled back. Transaction
rollback typically
causes the persistence context to be in an inconsistent state at the point of rollback. In
the state of version attributes and generated state (e.g., generated primary keys) may be
Instances that were formerly managed by the persistence context (including new instances that
made persistent in that transaction) may therefore not be reusable in the same manner as other
objects—for example, they may fail when passed to the merge operation.[16]"

Resolving this discrepancy will address the case that I'm looking at in particular, but will
not address the case where the getReference() method is invoked outside a transaction but
in an extended persistence context.

> JTA transaction rollback, nonexistant instances, transactional persistence context =>
failures during afterCompletion() and close()
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: OPENJPA-102
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa, kernel
>         Environment: WebLogic Server 10.0
>            Reporter: Patrick Linskey
>         Attachments: openjpa-detach.patch
> Configuration: 
>   - transactional persistence context
>   - DetachState=fgs
>   - JTA transactions
> If an error causes the transaction manager to roll back the current transaction, BrokerImpl.afterCompletion()
will be invoked with Status.STATUS_ROLLEDBACK. afterCompletion() will call,
which will attempt to load the default fetch group. If there is an instance in the Broker's
context that does not exist (that was looked up via EntityManager.getReference(), for example),
then the code in free() will fail with an ObjectNotFoundException.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message