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 Fri, 25 Jul 2008 18:42:41 GMT

Hi,
1. As persistence context is TRANSACTION scoped, the context will terminate
(by Spring or whomever) after every transaction and all managed instances
will be detached. btw, OpenJPA does allow programmatic detach through
extended OpenJPAEntityManager API. However, from the description, it seems
instances are getting detached all right and as merging context is a new
transaction-scoped context -- hence these areas are unlikely cause of the
conflict.

2. Another angle: are you enhancing at run-time or build-time? Noticed few
anomalies with runtime enhanced entities dirty state transitions. To narrow
the source of error, it is advisable to enhance the entities at build-time.

3. Is it possible to switch to a long/int version field rather than
timestamp? Again not permanently but to narrow down the cause.  

4. If possible, post the error stack. 

5. Are you flushing before queries?




Tim Holloway wrote:
> 
> On Thu, 2008-07-24 at 15:18 -0400, Tim Holloway wrote:
> 
> I've appended some additional info.
> 
>> 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
>> detach
>> B. Probably this, but
>> C. Maybe this
>> D. JDO2 supports explicit detach, but if JPA does, it's not obvious to
>> me.
>> 
>> The service class uses the following mechanism for injection of the
>> EntityManager:
>> 
>> 	
>> 	@PersistenceContext
>> 	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
>> binding.
>> 
>> > 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? 
>> >    
>> 
>> TRANSACTION
>> > 
>> > 
>> 
>> 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.
> 
> I can't find it in an FM yet, but the default operation of the Spring
> transaction framework is to detach at the end of the transaction
> according to several informal sources. This makes it consistent with
> Hibernate and ensures that the objects are POJOS and need no DTOs. My
> debugger verifies that at all times in my business layer the objects are
> in fact detached.
> 
> For those who prefer lazy-loading, there's a filter to prevent this, but
> I didn't design the app to lazy-load anyway.
> 
> I was wrong - the results of the find query are NOT the identical object
> as what came back from the merge. However, I'm at a loss as to why the
> merge isn't resetting the dirty flags and why the output from the merge
> is considered as older than the persistent data.
> 
> This is the versioning definition:
> 
> 	@Basic
> 	@Column(name="change_time", nullable=false)
> 	@Version
> 	private Timestamp changeTime;
> 
> The merge returns an updated changeTime. The query returns the same
> changeTime. Only the "dirty flags" distinguish them.
> 
> 
> 

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


Mime
View raw message