db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lindauer" <elinda...@gmail.com>
Subject Re: feature request
Date Thu, 01 Nov 2007 23:21:18 GMT
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 interface.

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

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.
> Regards,
> Craig
> 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