>>
>> We need to talk a little bit here - my long term notion for the
>> finderresults was to extend it into the invoker layers so that the
>> collection that a client gets from these would be a proxy over the
>> finder results. At that point we could add a 'page-size' parameter and a
>> protocol between the client proxy and the server-side FinderResults to
>> request that a new page of entities be brought into memory. This would
>> allow us to support finders returning truly huge result sets without
>> crashing out on memory. Naturally, this would really only be useful from
>> batch processes for example (no matter how well we optimize, no user is
>> going to sit while the software goes through 10 million rows!), so the
>> real utility of it could easily be questioned.
>> Would such a feature seem useful to you? Any others with opinions on the
>> matter?
>>
>
>
> Yeah, I saw your comment in CMPPersistenceManager. It's a great idea!
>
> But, I just don't like having code hanging around that isn't being used and
> is there for "possible future features". What happens sometimes is that the
> future feature is never implemented and different people end up maintaining
> that code base and are confused about why the code is there. IMHO,
> FinderResults isn't being used now, so it should be removed until the
> 'remote cursor' feature is added.
Good enough. We're also going to have to coordinate with Dain to make
sure that these optimizations get over into the 2.0 CMP stuff. I've only
looked at that briefly so far.
-danch
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
