db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christiaan <christiaan...@hotmail.com>
Subject Re: Embedded object and evict
Date Fri, 29 May 2009 10:43:02 GMT

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. 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();
address.setZipCode("1234"); //would this work?

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 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.
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.

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.

View raw message