xml-xindice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Rosenbaum <Te...@amicas.com>
Subject Re: ResourceIterator service needs some improving...
Date Fri, 06 Feb 2004 06:32:01 GMT
The problem is that the ResourceSetImpl iterates over the
results, adds each resource in the result as a child node of a single 
result document,
turns that document into a String, and then uses the String to
produce an XMLResource that is the result sent back to the

This blows up when the result set is large due to the toString() operation.

I implemented a LazyResourceSetImpl patch that is in Bugzilla.
That works for the embedded driver case, but the situation is
more complex for XMLRPC solution.

The implementation probably needs to be something like the
different kinds of ResultSet that you can support under JDBC.
e.g. forward only vs. random access, etc. so you could support
lazy retrieval. As it stands now, the ResourceSet returned
supports full random access which is at odds with a lazy
implementation. It might be possible to define a new kind
of query service that returns a ResourceSet with different
behavior (so as not to break any existing applications that
rely on the random access nature of the current ResourceSet).
Or, perhaps some configuration or dynamic control to set
the behavior of ResourceSet.

The bugzilla bug is 22157 


Vadim Gritsenko wrote:

> webhiker@tiscali.fr wrote:
>> Has anyone written a better iterator service for Xindice/Xml:db to 
>> get over the limitation of throwing an out-of-memory exception if your
>> Xpath query returns too many results?
>> It seems that the default behaviour for Xindice at least, is to 
>> return ALL the results in the ResourceIterator instead of using some
>> server-side paging mechanism, so our xindice client code regularly 
>> gets nasty out of memory exceptions..
>> Since we have noe way of knowing if an Xpath is going to return large 
>> result sets or not, I would have thought this would be a natural 
>> behaviour
>> for listing/querying a collection.
>> Anyone have any other ideas to approach this problem?
> Does it return all the documents? Or keys only? One idea is to return 
> only keys, this should help a  lot.
> Vadim

View raw message