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 20:03:05 GMT
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? 
> >    
> > 
> > 
> 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:

	@Column(name="change_time", nullable=false)
	private Timestamp changeTime;

The merge returns an updated changeTime. The query returns the same
changeTime. Only the "dirty flags" distinguish them.

View raw message