Experts, I've reviewed the specification and I propose a solution.
On Mar 30, 2009, at 10:19 AM, David Ezzio wrote:
Hi Craig, Before rushing off to create a TCK test for this use case, it would be useful to create some language in the spec which the test can verify.
I agree.
According to section 18.15, "The embedded attribute applied to a field of a persistence-capable type specifies that the implementation will treat the field as a Second Class Object." In section 6.3, the extensive discussion of SCO's leaves little doubt that a perfectly acceptable implementation solution for what to do when a SCO is evicted is to clear the FCO's referring field.
In fact, 12.6.1 is definitive that the FCO's referring field must be cleared:
clears persistent fields on each instance (sets the value of the field to its Java default value);
The FCO field is set to null; thus, the SCO is no longer referenced by its owner; thus the SCO is orphaned and no longer can be managed. By the way, this treatment is exactly how a String or Date would behave.
(It would be nice if the issue of evicting a SCO was discussed when the evict methods are defined, but it is not.) What is not clear is what should happen after an embedded PC object is evicted. If the PC class is marked as embedded only, then there is no reason for any of its objects to have a JDO identity. On the other hand, if the PC class is not marked embedded only, then it sounds reasonable to me that the spec might require that an object previously assigned to an embedded field should now acquire a JDO identity.
This would conflict with the idea that an SCO has an owner responsible for its persistent state.
On the other hand, it also sounds reasonable to me that it wouldn't. Instead, the spec might require that the application call makePersistent on the now unreferenced and previously embedded PC object. At the present, the spec doesn't tell us what should happen, so either behavior is allowed.
I believe that there is no way for an SCO to acquire an identity simply by being un-referenced by its owner. That would imply a state transition that isn't documented.
As always, my preference is that one rule be applied as widely as possible for simplicity's sake. So therefore, I propose that we consider only two possible rules: One, embedded and persistent PC objects (whether the class is embedded-only or not) always become transient when evicted,
This is problematic because evict has never forced a transition to transient.
or two, all persistent PC objects when evicted remain persistent, whether they are embedded or not.
This is problematic because the owning field is cleared by the semantics of evict, and therefore the SCO no longer is associated with a persistent instance. So it can't be persistent.
Neither rule is clearly applied in the specification to the use case here.
My proposed solution is to add text to 12.6.1: clears references to embedded SCO instancesAlthough it isn't explicit in the specification, to me a reasonable life cycle state for all SCO embedded instances is "transient". From 6.3, "The behavior of embedded persistence-capable types is intended to mirror the behavior of system types". And all throughout this discussion of SCOs, they are treated as if they had no identity or persistent behavior apart from their owning FCO. There is no need for them to report themselves as dirty, or persistent, or anything else, since all of their state is managed by their owner.
I could see an argument for having a currently-owned SCO delegate all state interrogation methods to its owner. I can also see an argument for creating a new state called "owned" specifically to handle this. I could see an argument for having an SCO be able to return its StateManager but return null to an identity query. But any of these alternatives has its own set of problems.
Returning to the use case, what is the requirement for an SCO to report its persistent state apart from its owner?
Craig
Cheers, David Craig L Russell wrote:If this isn't covered by a TCK test, perhaps it should be. Any volunteers? Craig On Mar 27, 2009, at 9:42 AM, Michael Bouschen wrote:Hi Christiaan,I think the embedded instance is still persistent after the evict call. It's life cycle state might change to hollow, but even then it is still persistent. So isPersistent should return true for both calls.Regards MichaelHi,suppose I have an embedded persistent object Address part of a persistentobject Company. What should be printed for the following code Address address = company.getAddress();System.out.println("persistent: " + JDOHelper.isPersistent(address));pm.evict(address);System.out.println("persistent: " + JDOHelper.isPersistent(address));kind regards, Christiaan-- *Michael Bouschen* *Prokurist* akquinet t...@spree GmbH Bülowstr. 66, D-10783 Berlin Fon: +49 30 235 520-33 Fax: +49 30 217 520-12 Email: [email protected] Url: www.akquinet.de <http://www.akquinet.de> akquinet t...@spree GmbH, Berlin Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth Amtsgericht Berlin-Charlottenburg HRB 86780 B USt.-Id. Nr.: DE 225 964 680Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
