Quoting Kevin O'Neill <[EMAIL PROTECTED]>: > Why is it obviously more performant?
The driver cannot do less work than simply piping results through to the user at the very moment when they arive. No memory required (in the case of SAX events). No object generation. No administrative work. It's that simple. (Always think of the trivial processing task to write the result set into a servlets output stream. In this case the attached SAX handler might be a trivial XML Writer or something similar.) > How does the push model work in a stateless environment like http? > Couldn't the push be laid over and iterator? How do I implement a skip > type process, eg I only want results 6 though 10? What is the problem with HTTP? The HTTP response contains a single result set, no matter how large. The result set is typically returned as a single, large XML document. (Best for performance, it may also be a set of documents, for example in a MIME multipart document, in which case an XML parser has to be invoked for any result document, which is slower.) The driver typically creates a SAX parser consuming the input stream and attaches a SAX ContentHandler parsing the response. The SAX handler checks for error conditions and document boundaries, forwarding SAX events to the user. > Is the connection to the store local or remote? Whatever you want. In my personal case it has been a Tamino database engine and the protocol was the proprietary Tamino response document, but that's not too different from an XML-RPC or SOAP response besides use of different tags. Jochen
