These TTLs are just hints, not promises. If the result set TTL says 100
seconds of idleness and the session goes with 50 seconds of idleness, then I
guarantee that the result set will go away with the session.
What's the problem?
> -----Original Message-----
> From: Robert Sanderson [mailto:[log in to unmask]]
> Sent: Wednesday, June 19, 2002 9:49 AM
> To: [log in to unmask]
> Subject: Re: Betr.: SessionID Summary
> > >Will sessionids have a TTL as well? In which case a
> resultset with a TTL
> > >longer than the session's TTL is just incorrect.
> > >If they don't have a TTL, then are they just silently
> expired with no
> > >warning? In which case I would suggest that sessions
> shouldn't be expired
> > >while they have resultsets that still have time left to
> live as this is
> > >contrary to the only information presented to the client.
> > I would say, that it is preferred that resultsets time out
> later than
> > sessions but when it is the other way around, the client
> could save the
> > original CQL to re-execute the query.
> The seems very strange to me. Surely the implication of
> having a result
> set last longer than the session is that result sets can be
> accessed out
> side of a session?
> But if you're going to have sessions and I assume limit access to
> resultsets to only those created during that session, what is
> the point of
> having them last longer than the session?
> This isn't rhetorical, maybe there is a reason, but I can't
> think of one
> ,'/:. Rob Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Special Collections and Archives, extension 3142
> ,'---/::::::::::. Twin Cathedrals: telnet:
> liverpool.o-r-g.org 7777
> ____/:::::::::::::. WWW:
I L L U M I N A T I