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" <[EMAIL PROTECTED]>
To: "Apache JDO project" <[email protected]>; "JDO Expert Group"
<[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
*To:* Apache JDO project <[email protected]> ; JDO Expert
Group<[EMAIL PROTECTED]>
*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 <[EMAIL PROTECTED] > 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:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>
>
