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?
Ralph
> -----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
>
> --
> ,'/:. 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:
http://liverpool.o-r-g.org:8000/
I L L U M I N A T I
|