[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: resultSetIdleTime (Purpose of)
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 ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]