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 Re: serialize Detachable instance for storage
Date Sat, 25 Mar 2006 01:39:44 GMT
Hi,

I agree on all points as well. I'll add this to the errata for JDO  
maintenance.

By the way, Andy, if you have a test case that you can point me to (I  
hope it's in the repository) we can add it to the TCK or at least  
implement the ideas contained therein.

Thanks,

Craig

On Mar 24, 2006, at 12:22 PM, Matthew T. Adams wrote:

> I agree on all points, Andy.  Craig, I would think it to be  
> beneficial to
> explicitly state something about what compliant implementations  
> should do
> when serializing instances for the purposes of embedded storage  
> versus for
> any other reason.
>
> It is not currently discussed, although it does seem intutive for  
> the JDO
> implementation to handle this situation correctly.
>
> --matthew
>
>> -----Original Message-----
>> From: Andy Jefferson [mailto:andy@jpox.org]
>> Sent: Friday, March 24, 2006 11:51 AM
>> To: jdo-dev@db.apache.org; jdo-experts-ext@sun.com
>> Subject: RE: serialize Detachable instance for storage
>>
>>
>> Hi,
>>
>>> I now understand your issue.  If you declare a PC class that
>> is detachable
>>> to also be serialized in another class, how do you prevent
>> the detachment
>>> algorithm from running when the instance is being
>> serialized/deserialized
>>> for the purposes of persistent storage versus being
>> serialized/deserialized
>>> for any other reason?  After all, the desired behavior, I
>> think, is to store
>>> embedded serialized instances as they are in their current
>> state, not in a
>>> detached-clean or detached-dirty state.
>>
>> Agreed. Storage in a datastore and retrieval from the
>> datastore should be
>> transparent to the user, and should not involve detachment.
>>
>>> // Q1:  During storage, 'address' will be serialized, due to
>> metadata requirement
>>> and serialized objects are implicitly detached according to
>> spec section 12.6.8.
>>> Is the address stored in the database detached?
>>
>> I say no.
>>
>>> // Q2:  Does 'address' reference a detached instance now because of
>>> serialization of Person.address?
>>
>> I say no.
>>
>>> Does that mean then, that an Address deserialized from the
>> data store is
>>> detached-clean or persistent-clean?
>>
>> persistent-clean. If the user updates a field on a serialised
>> PC object, whilst
>> within the txn, they would expect it to make it into the
>> datastore. If the object
>> is detached it has no StateManager and so any change will not
>> be persisted.
>>
>>
>> The implementation can easily detect when it is serialising an
>> object for storage
>> in the datastore (as opposed to any normal call to
>> StateManager.preSerialize()),
>> and JPOX CVS currently assumes that the storage of serialised
>> PC's does *not*
>> contain the detach state.
>>
>> PS. There are no TCK tests that check on this currently, as
>> noticed when we had
>> implemented it in a pure JDO2 spec way, detaching all
>> serialised objects. JPOX
>> does however have its own unit tests that do check this situation.
>>
>> --
>> Andy
>>
>
>

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