Re: Embedded object and evict

[Craig L Russell]

Hi Christiaan,














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

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.

embedded objects very different from "normal" persistent objects.

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

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();


is lost or not:

before the commit and evict.

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

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>

</spec>

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,

would be good idea as well.


case the embedded object behaves the same as its owner. All mentioned

embedded, only difference would be at database level.

explicitly mentioning that fields of the embedded objects are not nullified 2) if the association is not lost fields can be nullified because in that scerios would work since there would be no difference between normal and

Craig

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

cycle changing APIs.

Craig

On May 26, 2009, at 3:14 AM, Christiaan wrote:

owner. It's never dirty, and can't be the parameter of any of the life

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

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.

decision whether a class should be embedded or not. So making it more

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@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.russ...@sun.com
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature