You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Eric Lindauer <el...@gmail.com> on 2007/11/02 00:21:18 UTC
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 <Cr...@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!
>
>
>
Re: feature request
Posted by Chris Beams <cb...@gmail.com>.
On Nov 3, 2007, at 1:43 AM, Andy Jefferson wrote:
> I like Ilans ideas for signatures, and would have
> getManagedObjects(ObjectState ... states);
> getManagedObjects();
+1
Re: feature request
Posted by Andy Jefferson <an...@jpox.org>.
> We can also consider having two methods:
> Object[] getManagedObjects(ObjectState state)
> Object[] getManagedObjects(Set<ObjectState> states)
> or maybe even better:
> Object[] getManagedObjects(ObjectState... states)
+1 on adding a method/methods to PersistenceManager
+1 on the name "getManagedObjects".
Return type : I have no preference over Collection or Object[]
I like Ilans ideas for signatures, and would have
getManagedObjects(ObjectState ... states);
getManagedObjects();
The final method could also be present in "jdo2-api-legacy" jar too so this
capability is then available for people still using JDK1.3, 1.4.
This should be in JDO2.1 since it should be trivial to implement (and some
implementations already have this type of custom capability).
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: feature request
Posted by Ilan Kirsh <ki...@objectdb.com>.
We can also consider having two methods:
Object[] getManagedObjects(ObjectState state)
Object[] getManagedObjects(Set<ObjectState> states)
and then you will be able to get all the objects that you need in one call:
Object[] newOrDirty = pm.getManagedObjects(EnumSet.of(
ObjectState.PERSISTENT_NEW, ObjectState.PERSISTENT_DIRTY));
or maybe even better:
Object[] getManagedObjects(ObjectState... states)
and then you will use just:
Object[] newOrDirty = pm.getManagedObjects(
ObjectState.PERSISTENT_NEW, ObjectState.PERSISTENT_DIRTY);
----- Original Message -----
From: "Eric Lindauer" <el...@gmail.com>
To: "Apache JDO project" <jd...@db.apache.org>; "JDO Expert Group"
<jd...@sun.com>
Sent: Friday, November 02, 2007 4:14 AM
Subject: Re: feature request
> 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 <ki...@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 <el...@gmail.com>
>> *To:* Apache JDO project <jd...@db.apache.org> ; JDO Expert
>> Group<jd...@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!
>> >
>> >
>> >
>>
>
Re: feature request
Posted by Eric Lindauer <el...@gmail.com>.
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 <ki...@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 <el...@gmail.com>
> *To:* Apache JDO project <jd...@db.apache.org> ; JDO Expert Group<jd...@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!
> >
> >
> >
>
Re: feature request
Posted by Ilan Kirsh <ki...@objectdb.com>.
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
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 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!