not very robust. Of course we could always ignore the getResource(index) method of ResourceSet....
;>
Perhaps I should take me questions to XmlDB, sicne it seems a hge shortcoming even in Mickey Mouse database systems to have some form of paging of retrieve query results etc.
Thanks for the feedback. WH.
Terry Rosenbaum wrote:
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
client.
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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22157>. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22157)
-Terry
Vadim Gritsenko wrote:
[EMAIL PROTECTED] 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
