db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: feature request
Date Fri, 02 Nov 2007 02:57:31 GMT
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" <elindauer@gmail.com>
To: "Apache JDO project" <jdo-dev@db.apache.org>; "JDO Expert Group"
<jdo-experts-ext@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 <kirsh@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 <elindauer@gmail.com>
>> *To:* Apache JDO project <jdo-dev@db.apache.org> ; JDO Expert
>> Group<jdo-experts-ext@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!
>> >
>> >
>> >
>>
>



Mime
View raw message