db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: Reflection-based JDO implementations
Date Tue, 03 Oct 2006 23:31:15 GMT
Hi Craig,

The suggestion looks good. A small addition to (3) - Field comparison is also required when
isDirty is called, and I think that also when isTransactional is called (at least in optimistic
transactions to identify a non transactional object that became dirty). Also the preDirty
and postDirty lifecycle events should be adjusted.

Regards,

Ilan
  ----- Original Message ----- 
  From: Craig L Russell 
  To: Apache JDO project ; JDO Expert Group 
  Sent: Wednesday, October 04, 2006 12:59 AM
  Subject: Reflection-based JDO implementations


  Javadogs,


  The specification currently leans in the direction of reflection-based implementations in
not requiring an exception to be thrown upon accessing a field of a deleted instance (which
is only possible to do via enhancing the class to intercept all field accesses for deleted
instances). There has been a request to go farther in this direction by allowing reflective
implementations to pass the TCK.


  For the purposes of this discussion, I'll propose a definition of reflective implementation.
It is an implementation that does not rely on enhancement of persistence-capable classes,
and implements the StateInterrogation interface and registers the implementation object with
the JDOImplHelper class for state interrogation of persistence-capable classes. It uses some
unspecified (implementation-specific) mechanism for identifying persistence-capable classes.


  There are a few implications with this proposal. For reflective implementations:


  1. Persistent instances must be fully populated when they first become managed, since field
accesses are  not detectable. This applies to makePersistent, attachCopy, and query. 


  2. Fields declared as references to persistence-capable instances must be fully populated
as well, transitively, upon first access. 


  3. Changes must be detected by field comparison at flush time to determine if any fields
have been changed and must therefore be flushed to the datastore. 


  4. At commit time, either the DetachAllAtCommit must be true or RetainValues must be true.
This is the only way field accesses outside a transaction would be valid.


  5. At transaction begin for datastore transactions, all managed instances must be refreshed
from the datastore and thereby transition to persistent-clean. This is the only way to adhere
to the semantics of datastore transactions (since the implementation doesn't detect field
accesses, it's not possible to refresh at first access of a field). 


  6. There is significant rework needed for the state transition chapter when considering
the above implications, and corresponding rework in the TCK.


  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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message