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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
