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.bI 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 FetchPlanDoes 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
