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 Fri, 02 Nov 2007 02:14:27 GMT
Excellent addition Ilan.  I wasn't aware of the ObjectState addition
in 2.1until now.  In my case, grabbing the persistent dirty and
persistent new
objects just before a commit would give me exactly the set of objects I
need.

Thanks for the feedback.
   -Eric



On 11/1/07, Ilan Kirsh <kirsh@objectdb.com> wrote:
>
>  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)
>
> Regards,
>
> Ilan Kirsh
> ObjectDB Software
> http://www.objectdb.com
>
>
> ----- Original Message -----
>  *From:* Eric Lindauer <elindauer@gmail.com>
> *To:* Apache JDO project <jdo-dev@db.apache.org> ; JDO Expert Group<jdo-experts-ext@sun.com>
> *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 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
> 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.
>       Eric
>
>
>
>
>
> 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!
> >
> >
> >
>

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