openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Holloway <>
Subject Re: QUERY: detach/merge behavior
Date Wed, 23 Jul 2008 23:03:33 GMT
Unfortunately, that's rather murky in this context. The service layer is
responsible for commit or rollback, so there shouldn't be a "hanging
commit" - which is what I read this excerpt to be addressing.

Just to make life more fun, in JSF, it isn't as obvious where the detach
is being done. In Struts, I knew definitively that I was going to
release the connection at the end of the application logic (action) and
before the View referenced the object graph, but the JSF lifecycle is
more complex and I haven't tried to formally map it out. All I know is
that by the next trip in (HTTP Request), the session datamodel objects
have been detached for me.

Urg. Just remembered. I'm using Spring to do the transaction management
so it's supposed to handle the commit/rollback for me. Just to make
things even more subtle.

On Wed, 2008-07-23 at 12:25 -0700, Pinaki Poddar wrote:
> Hi,
>   Following excerpt from Chapter 11 [1] of the manual may be relevant in
> this context: 
> "When detaching an instance that has been modified in the current
> transaction (and thus made dirty), the current transaction is flushed. This
> means that when subsequently re-attaching the detached instances, OpenJPA
> assumes that the transaction from which they were originally detached was
> committed; if it has been rolled back, then the re-attachment process will
> throw an optimistic concurrency exception.
> You can stop OpenJPA from assuming the transaction will commit in the
> following ways :
>     * Invoke EntityTransaction.setRollbackOnly prior to detaching your
> objects. Setting the RollbackOnly flag prevents OpenJPA from flushing when
> detaching dirty objects; instead OpenJPA just runs its pre-flush actions
> (see the OpenJPAEntityManager.preFlush Javadoc for details).
>       This allows you to use the same instances in multiple
> attach/modify/detach/rollback cycles.
>     * Make your modifications outside of a transaction (with
> NontransactionalWrite enabled) before detaching.
>     * Set flushBeforeDetach to false (see Compatibility.setFlushBeforeDetach
> Javadoc ). This option is similar to the first option, but does not affect
> the current transaction."
> [1]

View raw message