openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: QUERY: detach/merge behavior
Date Thu, 24 Jul 2008 14:42:18 GMT

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?

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

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.

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? 

     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? 

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? 
   


-- 
View this message in context: http://n2.nabble.com/QUERY%3A-detach-merge-behavior-tp578652p580403.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.


Mime
View raw message