db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: detachOnCommit + J2EE / detachOnClose
Date Fri, 03 Mar 2006 23:58:44 GMT
Hi Marco,

Please read the description of the FetchPlan in the final  
specification. Look specifically at the flags DETACH_LOAD_FIELDS and  
DETACH_UNLOAD_FIELDS, as they directly speak to your concerns below.

If you have further questions, please follow up. After all, this is a  
specification, not a user guide. ;-)

Regards,

Craig

On Mar 3, 2006, at 5:51 AM, Marco Schulze wrote:

> Hello Craig,
>
> thank you very much for your response and clarifications!
>
>
> First:
> 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:
>
> a.anotherA
> a.listOfA
> a.b
>
> 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.
>
>
> Second:
> 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 :-)
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message