resultSetIdleTime (Purpose of)

["Hammond, Tony" <t.hammond@nature.com>]

Hi:

(Sorry to have to leave the meeting so abruptly, but there was a knock on
the door.)

I just wanted to follow up here about resultSetIdleTime and its purpose. As
I understand it this seems to be to support light-weight clients who want to
be drip fed results from a known (identified) set.

Our implementation, however, does not support this model. To avoid trashing
the backend database we assign a resultSetId which refers to a *by
reference* result set. In fact, the resultSetId is paired off with the query
string and stored in a memcache instance so that it can it can be accessed
by any node in the server cluster. This memcache entry has a ttl. We
therefore can guarantee to serve the same result set (modulo any updates)
within the ttl (as negotiated between server and client). We can make no
guarantees for a resultSetIdleTime which would arise from rejuvenating the
memcache entry.

(Note that in practice we set a max ttl of 3600s so can reasonably expect
that there will be limited updates during this period. But no guarantees.)

We could, it is true, always refresh our memcache entry on any queries by
resultSetId, although we don't do that at present. (And here, I'm still
confused as to why we couldn't just reset the ttl instead of using a
separate resultSetIdleTime.)

This all gets fearfully complicated. Do we really need to support this level
of complexity?

My primary concern is for server viability without which nothing else
follows.

Cheers,

Tony


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************