From jdo-dev-return-6732-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Fri Nov 02 01:36:29 2007 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 87766 invoked from network); 2 Nov 2007 01:36:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Nov 2007 01:36:29 -0000 Received: (qmail 56809 invoked by uid 500); 2 Nov 2007 01:36:17 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 56798 invoked by uid 99); 2 Nov 2007 01:36:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 18:36:17 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [212.150.49.174] (HELO mtaout4.barak.net.il) (212.150.49.174) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 01:36:34 +0000 Received: from ILANC ([82.166.155.8]) by mtaout4.barak.net.il (Sun Java System Messaging Server 6.2-7.04 (built Aug 17 2006)) with ESMTPA id <0JQU00K6UV3Q1UT0@mtaout4.barak.net.il> for jdo-dev@db.apache.org; Fri, 02 Nov 2007 03:35:52 +0200 (IST) Date: Fri, 02 Nov 2007 03:34:56 +0200 From: Ilan Kirsh Subject: Re: feature request To: Eric Lindauer , Apache JDO project , JDO Expert Group Reply-to: Ilan Kirsh Message-id: <000e01c81cf0$b5cdeec0$0500000a@ILANC> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="----=_NextPart_000_0009_01C81D01.56BFEAD0" X-Priority: 3 X-MSMail-priority: Normal References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_NextPart_000_0009_01C81D01.56BFEAD0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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 -----=20 From: Eric Lindauer=20 To: Apache JDO project ; JDO Expert Group=20 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.=20 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.=20 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.=20 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.=20 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.=20 Thanks for your consideration. Eric =20 On 10/31/07, Craig L Russell wrote: Hi Eric, Right list. If the biggest need you have is to recognize when objects have=20 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,=20 > > 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=20 > 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:=20 > > 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=20 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp! ------=_NextPart_000_0009_01C81D01.56BFEAD0--