Hello JDO team,

I just came back from holidays and it seems I'm too late as you already
voted. But still, I'd like to mention an issue about the feature
detachOnCommit: When using a JDO implementation within a J2EE server,
this feature IMHO doesn't make much sense, because the transaction might
be committed/rolled back later than the object needs to be detached.
This is especially true when using XA transactions. Additionally, it is
possible (at least some JDO implementations support it) to read data
without having any transaction (i.e. non-transactional read).

In both cases, it would be necessary to have additionally a
detachOnClose feature. Means, whatever happens first (commit transaction
or close persistence manager) should cause the objects to be detached.

To make things clearer, I'd like to shortly explain the handling
difference between non-J2EE and J2EE: When using JDO outside a managed
environment, the workflow works like this:

1. open the persistence manager
2. open a transaction
3. work with JDO objects
4. commit/rollback the transaction
5. close the persistence manager

All the above steps are performed explicitely by the programmer.

Within a J2EE container (i.e. within an EJB method), things are different:

1. J2EE opens a transaction for you _implicitely_ (the transaction
might involve many servers; thus it might already exist before the
EJB method is triggered)
2. obtain a persistence manager
3. work with JDO objects
4. close the persistence manager
5. J2EE commits/rolls back the transaction _implicitely_

A JDO object will be sent to the client using native serialization
either between 4 and 5 (with XA transactions) or after 5 - though I'm
not completely sure, it might be always between 4 and 5 even with local
transactions.

JPOX fortunately already supports detachOnClose as a vendor extension,
but IMHO this feature deserves to be integrated into the JDO standard.

Best regards, Marco :-)

--
 ________________________________________
______
Marco Schulze                   NightLabs GmbH
Rehlingstr. 6d
79100 Freiburg
Germany

eMail:  Marco@NightLabs.de
Fon:    +49-761-2 111 793
Fax:    +49-761-2 111 798
WWW:    http://www.NightLabs.de

Geschäftsführung:
Marco Schulze <Marco@NightLabs.de>
Niklas Schiffler <Nick@NightLabs.de>

Eintragung:
Amtsgericht Freiburg, HRB 6186
 ________________________________________
______

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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 :-)

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]