db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Schulze <Ma...@NightLabs.de>
Subject Re: detachOnCommit + J2EE / detachOnClose
Date Fri, 03 Mar 2006 13:51:22 GMT
Hello Craig,

thank you very much for your response and clarifications!

You are absolutely right that the PersistenceManager which I get in a 
J2EE server is only a proxy. I understand the current JPOX 
implementation this way, too. Could the detaching occur already when the 
PM _proxy_ is closed? If I understand you correctly, then this is not 
possible, because the same _real_ PM might be used by multiple EJBs (if 
they act within the same transaction). On the other hand, I cannot use 
the detachOnCommit feature, because it might detach too late - after I 
already serialized the object. Does that mean, within the J2EE server, 
there is no possibility at all to get an object detached in exactly the 
same form that has been resolved while it was still attached to the 
datastore? :-(

Unfortunately, there are situations when the needed object graph is very 
complex and cannot be formulated using fetch-groups (I currently have 
that situation). This is because multiple instances of the same class 
occur in a nested form:


I don't want a.anotherA.b and I don't want a.listOfA.b, but I want a.b. 
What can I do to get exactly this? The possibility of detaching the 
currently resolved form of an object would be very helpful. If I could 
explicitely do a pm.detachCopySnapshot(a) or 
pm.getFetchPlan().setSnapshotMode(true) + pm.detachCopy(a), my problem 
would be solved, too.

Well, otherwise I have to manually detach all my different a-s and b-s 
and assemble the graph after detaching and before sending it to the client.

I thought detachOnCommit/detachOnClose would detach all objects in the 
level1-cache in exactly the same form as they have been resolved until 
that point in time.

But you wrote:
> During  the afterCompletion callback, the rest of the 
> DetachAllOnCommit  behavior occurs, which is the actual detachment of 
> the persistent  instances and the nullification of the relationship 
> fields that are  not part of the FetchPlan
Does that "not part of the FetchPlan" mean that the detachOnCommit 
wouldn't do what I need anyway?

Best regards, Marco :-)

View raw message