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 Reflection-based JDO implementations
Date Tue, 03 Oct 2006 22:59:08 GMT
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
View raw message