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 Tue, 31 Mar 2009 08:48:09 GMT

Hi,
The remarks I have regarding this:
1) A SCO does not have JDO-identity, but that doesn’t mean it does not have
persistent state.  An embedded (user defined) persistent capable object
represents an object in the datastore and thus returns true on
isPersistent(). A collection object usually is not stored in the datastore
and returns false on isPersistent(), both before and after evict(). It seems
to me that these things are sometimes mixed up in this discussion

2) The fact that the owning instance clears it reference to the embedded
persistent object, does not imply that the embedded persistent object clears
it reference to its owning instance. And even if the embedded object does
clear the reference to it’s owning FCO, the spec doesn’t prevent to share
the statemanager of the owning FCO, which is not needed be cleared by the
spec (it can, but it doesn’t have to).

3) The one thing that is clear is that evict() should transition an object
to the state hollow, a state which should be “invisible” to the application
according to the spec. It seems to me that if the evict() has an impact on
the return value of isPersistent(), this hollow state transition becomes
quite “visible” to the application

4) User defined persistent capable types can be embedded and non-embedded at
the same time, depending on their referring field. Decisions for this can
vary, eg. performance can be a factor. However, it feels unnatural that
state interrogation on the same type depends whether a call to evict has
been done.

5) Being “embedded” implies being a SCO is not always that clear in the
spec:
      28.4
The embedded attribute applied to a field of a persistence-capable type is a
hint to the implementation
to treat the field as if it were a Second Class Object. But this behavior is
not further specified
and is not portable.

>From an application point of view I use evict for 2 reasons: to free up
resources or to make sure the object has the latest changes in the datastore
when it’s fields are accessed. I use this in parallel to traverse large
trees of persistent objects and perform some algorithms (eg. comparising) on
it. In one of them it is tested whether the object is embedded. Currently
the outcome of the algorithm depends on whether evict has been called. 

Kind regards,
Christiaan

-- 
View this message in context: http://www.nabble.com/Embedded-object-and-evict-tp22738918p22800873.html
Sent from the JDO - Development mailing list archive at Nabble.com.


Mime
View raw message