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