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 Thu, 24 Jul 2008 19:18:55 GMT
OK, here goes...

On Thu, 2008-07-24 at 07:42 -0700, Pinaki Poddar wrote:
> Hi,
> > Unfortunately, that's rather murky in this context.
> Sounds like it.
> But let us try to clear the murkiness. Answer to following questions might.
> 1. Let X be an instance managed in persistence context C1 in transaction T1
> when X is detached.
> 2. what action triggered detachment of X? 
>          Commit of T1? 
>          Close of C1? 
>          Clearing of C1? 
>          Explicit programmatic detach?

Here's my understanding, occasionally muddled from exposure to similar
platforms such as JDO:

A. I didn't think that committing was supposed to be able to cause a
B. Probably this, but
C. Maybe this
D. JDO2 supports explicit detach, but if JPA does, it's not obvious to

The service class uses the following mechanism for injection of the

	public void setEntityManager(EntityManager entityManager) {
		this.entityManager = entityManager;

The service class methods only do queries, merge() and persist(). Any
other operation is coming from Spring or some other external non-visible

> 3. was X dirty or clean when it was detached from C1?

In all cases, X should have been clean.

> 4. is that detach trigger controlled explicitly by your application or is it
> happening implicitly by the other management artifacts of the environment?
> For example, X is getting detached because Spring  is closing the
> persistence context C1.

There is no explicit detachment here. As mentioned, anything above the
CRUD primitives is coming from outside.

> 5. There is no "hanging transaction". X gets modified out of any persistence
> context, and then X is merged to persistence context C2. 
>      C2 is definitely not the same as C1. Is that true?
>      Or is it that X gets merged to C1 but now C1 is running a different
> transaction T2? 

I haven't verified about the overall contexts, but I'm virtually certain
that the service manager is application-scoped and the entityManager is
injected once and only once in the life of the application.

Yes, these are 2 separate transactions, coming from 2 separate HTTP
requests. I have no actual need to detach at all, since these are all in
the same JVM, although it would not be a good idea in case the
HttpSession was serialized (e.g. load balance or cluster operations).
And, in fact, I am not doing anything explicit to cause detachment,
short of perhaps not fine-tuning framework options.

>      The document I referred addressed a different use case where modified X
> gets merged to original (C1,T1).
> 6. Does class of X has a version field? 

It does now. It didn't make any difference, however.

> 7. > 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. 
>    Yes it is not obvious -- because repeated chain of detach and merge to a
> series of different contexts is a supported use case. 
> 8. What is the scope of persistence context -- TRANSACTION or EXTENDED? 


What I find most vexing is that if I work with the object returned from
the merge(), I get the lock violation, but if I insert a
"findByPrimaryKey" query right after that, the object I get from the
query works just fine. By my understanding, the two objects should be in
an identical state, but in practice, the return from the merge has its
internal dirty field bits still set, but the results from the query do
not. Worse, I *think* the return from the query is not merely an
otherwise equivalent object - it's the exact same object. I think I'm
going to go back and verify that.

View raw message