[Mulgara-dev] Emailing: protocolServlet POST answercleanup.patch

[Paul Gearon]

On Tue, Jan 19, 2010 at 2:29 PM, David Smith <DMS at viewpointusa.com> wrote:
> Yes, how would that effect the .close()?

Subqueries result in subanswers, each of which need to be closed.
Interfaces that iterate over data for you are supposed to close these
as they go, but if they're not then you'll get these messages if the
log. Subqueries of this type don't exist in SPARQL (and SPARQL 1.1
subqueries have a different kind of structure), so new systems haven't
been testing this very much. Besides that, these messages are not
fatal, so even if we were testing those queries, they'd still be
passing.

So to check.... you said you're converting from SOAP to REST? Do you
mean that you were using the SOAP interfaces successfully, and now
you're moving over to using the REST interfaces instead?

> A side question (actually prompted by your query cancelation discussion)...
>
> Should REST clients still preserve the Jetty session? (we do), but I really have switched to using the POST auto commit handling around a POST query with multiple statements -- rather than doing our own autocommitt off/on.

The system does use the Session to cache the current connection. If
you don't preserve it, then it will ask for a new Connection each
time. Since the ConnectionFactory caches connections by server, then
if you don't store the http session then you'll possibly get the same
connection anyway.

> I see that mulgara connections are cached by the session, but it also seems that connections to the same server are "pooled".
> Is this correct?

Pretty much.

> >From a performance stand point would it be better to use sessions.

Do you mean HTTP sessions or Mulgara Session objects? All the same, if
you use HTTP sessions then it will come to the same thing (since the
session will refer to a Mulgara Connection, which wraps a Mulgara
Session). And yes, I'd use the same session wherever possible, since
it will prevent the possibility of reestablishing a new Connection.

Regards,
Paul