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! > > > > > > >
