db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: feature request
Date Fri, 02 Nov 2007 01:34:56 GMT
Hi Eric,

I think that this is a nice to have feature and also it seems easy to implement (unlike many
other JDO 2.0 and 2.1 features).

I would prefer the following method signature (in PersistenceManager not in Transaction):

Object[] getManagedObjects(ObjectState state)


Ilan Kirsh
ObjectDB Software

  ----- Original Message ----- 
  From: Eric Lindauer 
  To: Apache JDO project ; JDO Expert Group 
  Sent: Friday, November 02, 2007 1:21 AM
  Subject: Re: feature request

  Thanks for your time Craig.

  In regards to the various listener and callback interfaces... yes, I have looked at these
somewhat.  I'm aware of two, the InstanceCallbacks interface and the InstanceLifeCycleListener

  These mechanisms almost do what I need, but they are missing one thing.  Specifically, the
callbacks come back one object at a time. I want to respond to a transaction commit in the
following way:

  first: refresh / evict the corresponding instances of the changed objects in a separate
"read-only" PersistenceManager. 
  second: notify any interested listeners that the data in these object has changed.

  If the callbacks come back one object at a time, I can't evict all the objects before making
callbacks.  This may well mean that the listeners will have to redo whatever work they've
just done, since the data in the other objects is just about to change.  There is another
performance penalty here too... a listener who is registered with my code to receive notification
when, say, any object in Foo.class changes, will receive a callback for every changed Foo
object in a tx, when just one callback might do.  If the listener is responding by recalculating
an expensive cache, this could be a significant performance hit. 

  Note that PersistenceManager has both "refreshObject", and "refreshAll(Collection)", which
seems to be a nod to the fact that providing many objects at once can offer a performance
gain.  There is nothing corresponding to this for the calls coming back from JDO. 

  If we added a "getManagedObjects" to the PM interface, or a "getEnlistedObjects" to the
Transaction interface, you'd be set.  Now you can accomplish a bulk response to changes by
simply listening for, say, a transaction commit event, asking the tx for it's enlisted objects,
and doing whatever needs to be done. 

     Thanks for your consideration.


  On 10/31/07, Craig L Russell <Craig.Russell@sun.com > wrote:
    Hi Eric,

    Right list.

    If the biggest need you have is to recognize when objects have 
    changed, have you looked at the listeners and callback interfaces?
    These were put in for this kind of requirement.



    On Oct 31, 2007, at 1:43 PM, Eric Lindauer wrote:

    > Hi all, 
    > Long time JDO user, first time poster.
    > I'd like to see JDO include a mechanism for accessing all the
    > objects that
    > are:
    > a. enlisted in a particular transaction 
    > b. managed by a particular persistence manager in it's level 1 cache
    > Either would do for my purposes, though I think they are both
    > potentially
    > useful.  The most immediate need for these methods is to provide a 
    > mechanism
    > for an application to recognize when the data in a particular
    > PersistenceCapable object has changed, and make callbacks / refresh
    > data /
    > etc.
    > I propose the following method signatures: 
    > in javax.jdo.PersistenceManager:
    >     public Collection getManagedObjects();
    > in javax.jdo.Transaction:
    >     public Collection getEnlistedObjects();
    > Thanks for your consideration.  I apologize if I've written to the 
    > wrong
    > list.
    >      Sincerely,
    >       Eric Lindauer

    Craig Russell
    Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 
    408 276-5638 mailto:Craig.Russell@sun.com
    P.S. A good JDO? O, Gasp!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message