openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Holloway <>
Subject QUERY: detach/merge behavior
Date Wed, 23 Jul 2008 15:32:29 GMT
This probably rates coverage in the docs, since it's not obvious and I
haven't seen anything published on the issue.

In fact, I'd consider it a bug except that I've seen similar behavior in
Kodo JDO, so I can only assume I missed something here.

The issue has to do with using the detach/attach behavior in a local web
application context. This is an area that doesn't get much press - all
the usual examples have to do with shipping out objects remotely,
getting back the modified objects, and merging them.

However, in some environments - notably JavaServer Faces - there is
theoretically an advantage in working with detached objects that are
stored in an HttpSession. A JSF conversation can typically present a
form backed (directly or indirectly) by a datamodel object (forgoing a
distinct DTO). That datamodel object can then be merged. So far well and

The problem is, if that object - or the object returned from the merge -
is then later merged again, an OptimisticLockingException results and
the reasons aren't obvious.

The cure, as it turns out, is to discard the results of the merge,
re-fetch the object (e.g., by primary key) and then store that object in
the session so that it can be presented for the next set of changes.

Just to make things more interesting, the object returned from the merge
and the object fetched are often the same object, except that the fetch
appears to reset the "dirty" bits, which seems to be where the
OptimisticLockingException comes from.

Presumably, the overhead from a re-fetch is fairly low (cache hit), but
since merge is supposedly returning an updated object, the need isn't
obvious, so I'd like someone to tell me if that's the proper thing to

The environment that works most naturally here (tiered architecture) has
some quirks. Because of all the back-and-forth between the different
levels of the JSF system, it's not really possible to attach and set up
a transaction at the form level. Hence the need for a merge. The actual
data operations are done in a transactionally-wrapped service layer
method and the merge is done inside that method.

Any insights, document references, etc. will be greatly appreciated.

View raw message