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: Embedded object and evict
Date Fri, 29 May 2009 15:58:34 GMT
Hi Christiaan,

We have a defined major category of objects to deal with: first class  
objects that are persistent, have an identity in the datastore, and  
have an (elaborate) life cycle; second class objects whose values are  
persistent but have no identity and have a much simpler life cycle.  
Among the second class objects, we have user-defined classes,  
implementation-defined classes that implement system interfaces,  
mutable system classes, and immutable system classes.

I don't see the advantage of defining user-defined second class  
objects as having different behavior from system classes.

In your use case, you have first class objects for which you want to  
preserve the connection to the datastore but minimize the footprint.  
At an application-specific time you want to restore the values from  
the datastore. There is a life cycle for that: hollow.

You also want to restore the values of associated second class objects  
independent of the owning first class objects. This is the part that I  
don't understand. We don't allow restoring the value of second class  
objects of system types (Date, Timestamp, Collection) so your  
application needs to separate the handling of these objects from the  
handling of first class objects.

So I'd like to see us more sharply define the boundary between first  
and second class objects by treating second class objects as  
transient. This would normalize the treatment of user-defined second  
class objects to that of system-defined second class objects.

If you want to the other direction and define the behavior of second  
class objects, please think about the life cycle of second class  
objects and how they would respond to isDirty, isPersistent,  
isTransactional, isNew, isDeleted, and isDetached. And how they  
transition among life cycle states.

On May 29, 2009, at 3:43 AM, Christiaan wrote:

> I think the problem is not when an embedded object has persistent  
> behaviour,
> but when it loses this behaviour. Currently this makes the behaviour  
> of
> embedded objects very different from "normal" persistent objects.

Right. It makes the behavior identical to other second class objects.

> When calling evictAll() or doing a commit (with retainValues=false)  
> results a
> normal persistent object still behaves the same as it did before the  
> evict
> or commit. Having a reference to an embedded object, this object  
> suddenly
> becomes a new transient instance:
> Address address = company.getAddress();
> pm.evictAll()
> pm.getCurrentTransaction().begin();
> address.setZipCode("1234"); //would this work?

It would "work", but like date.setTime(), it would have no effect on  
the persistent instance.
> pm.getCurrentTransaction().commit();
> So when specifying "that object only has persistent behavior when  
> associated
> with an owner" I think it is also important to specify when this  
> association
> is lost or not:
> 1) if the association is lost (like it is now) The embedded object  
> should
> not nullify its fields but should contain the same information as it  
> did
> before the commit and evict.

The reason evict exists is to hollow out an instance and reduce its  
footprint in the vm. This means to remove all outward pointing  
references from the persistent instance. Then the garbage collector  
can remove the instances (unless you defeat this by holding a strong  
reference in the application).

> The above scenario would not work (nor does
> state interrogation), an additional company.getAddress() is  
> required. This
> would work for the scenario which I mention where one thread is  
> doing the
> reads, and the other doing the evicts or commits. This is how it  
> behaves
> now, which is workable, but it is important to make the behaviour  
> explicit.

This behavior is not specified. Since a long time ago,

<spec 6.3>
SCO fields of persistence-capable types are identified as embedded.  
The behavior of em-
bedded persistence-capable types is intended to mirror the behavior of  
system types, but
this is not standard, and portable applications must not depend on  
this behavior.

If we must standardize the behavior, I'm willing to do so but not by  
defining a quasi-persistent user-defined second class object life  
cycle. I think it's too late in the process to define a new category  
of persistence.
> Also since the evictAll() makes the embedded object non-persistent,
> explicitly mentioning that fields of the embedded objects are not  
> nullified
> would be good idea as well.
> 2) if the association is not lost fields can be nullified because in  
> that
> case the embedded object behaves the same as its owner. All mentioned
> scerios would work since there would be no difference between normal  
> and
> embedded, only difference would be at database level.

I'm still not clear why you want this behavior for user-defined second  
class objects and not objects like Date and Collection. Yes, you can  
define the behavior of user-defined second class objects as different  
from system-defined second class objects, but it's not trivial. And in  
my opinion, not worth the cost.

> Craig L Russell wrote:
>> I agree that embedded objects should be included in the spec. Right
>> now, there are hints but no specified behavior for embedded objects
>> with regard to the life cycle interrogatives and the behavior at
>> commit and evict.
>> I think the best approach is to treat embedded objects as transient
>> for all of the life cycle interrogatives. Then there is no question
>> about expected behavior after evict, commit, etc.
>> This does impact design. If you choose to make an embedded object,
>> then that object only has persistent behavior when associated with an
>> owner. It's never dirty, and can't be the parameter of any of the  
>> life
>> cycle changing APIs.
>> Craig
>> On May 26, 2009, at 3:14 AM, Christiaan wrote:
>>> Does this need to be addressed in the spec? Personally I feel that
>>> this
>>> technical design issue really impacts the decision of a designer
>>> whether a
>>> class should be embedded or not, whereas I think it should be a
>>> conceptual
>>> decision whether a class should be embedded or not. So making it  
>>> more
>>> explicit in the spec would at least be one thing to do.
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/Embedded-object-and-evict-tp22738918p23720315.html
>>> Sent from the JDO - Development mailing list archive at Nabble.com.
>> 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!
> -- 
> View this message in context: http://www.nabble.com/Embedded-object-and-evict-tp22738918p23777771.html
> Sent from the JDO - Development mailing list archive at Nabble.com.

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!

View raw message