db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Schulze <Ma...@NightLabs.de>
Subject detachOnCommit + J2EE / detachOnClose
Date Thu, 02 Mar 2006 09:19:34 GMT
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
______________________________________________


Mime
View raw message