db-jdo-dev mailing list archives

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 instances
Although 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 Michael
>>>
>>>> Hi,
>>>> suppose I have an embedded persistent object Address part of a
>>>> persistent
>>>> object 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 tech@spree GmbH
>>> Bülowstr. 66, D-10783 Berlin
>>>
>>> Fon: +49 30 235 520-33
>>> Fax: +49 30 217 520-12
>>> Email: michael.bouschen@akquinet.de
>>> Url: www.akquinet.de <http://www.akquinet.de>
>>>
>>> akquinet tech@spree GmbH, Berlin
>>> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
>>> Amtsgericht Berlin-Charlottenburg HRB 86780 B
>>> USt.-Id. Nr.: DE 225 964 680
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!