Women in Technology

Hear us Roar

Subject:   On becoming persistence-capable
Date:   2002-12-11 22:07:13
From:   srdrucker
Response to: On becoming persistence-capable

I think the best would be doing what you stated in a previous post:

[A "technically pure" JDO implementation would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.]

A JVM-Level hook would support three Major Goals:
-Provide ability to populate hollow data.
-Easily sense when an object becomes dirty.
-Support both field-level and public-interface level persistence (Sun JDO vs. java.bean.XMLEncoder style).

The hook could be modeled as follows:

-Add two new methods to Object:
addObjectListener(ObjectListener listener, String[] fields, Method[] methods) and removeObjectListener(ObjectListener listener).
-ObjectListener would have three methods, fieldRead(FieldEvent e), fieldWrite(FieldEvent e), invocation(InvocationEvent e)
-fieldRead(FieldEvent e) would provide opportunity to populate hollow data.
-fieldWrite(FieldEvent e) would provide sensing of dirty objects.
-invocation(InvocationEvent e) would provide both FieldRead and FieldWrite functionality for public interface persistence through monitoring of methods (usually getters and setters).

The fieldRead method would only be called once on the first access of each field registered (to provide the appropriate value if hollow). fieldWrite would be used to sense dirty state. invocation() would only be called the first time the method is invoked.

Finally, in my view, Object Persistence is the last hurdle to Java in the business world. I worry that Sun is not going to modify the VM for object persistence. There should be a jcp on this.

My 2 cents.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • On becoming persistence-capable
    2002-12-13 03:06:20  robin@ogilviepartners.com [View]

    You deliver good value for just 2c!

    I know that most members of the JDO (JSR12) Expert Group are reading this forum and we should have further input on this. However any alteration involving the JVM spec should be considered a long road to go down.

    In the mean-time the PersistenceCapable interface is facilitating persistence hooks that execute very quickly for enhanced versions of classes, whilst having no impact on un-enhanced classes.

    The domain object models and applications you persist with JDO today should be portable to future strategies of JDO implementation (VM hooks, "persistent" class modifier, etc.) when and if these arise.

    And remember that enhanced classes are not enhanced in a vendor-specific manner, but the same enhanced bytecode can be used with alternative JDO implementations. On the whole I believe that JDO provides a sound and future-proof architecture for transparent persistence.

    But that's my opinion. What do others think?

    Kind regards, Robin.