Date:         Thu, 20 Jun 2002 17:57:12 +0200
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Janifer Gatenby <[log in to unmask]>
Subject:      Re: is session id included in susequent request?
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

The client is free to ignore the session id but if it does then for our
server, it cannot re-use any previous result sets because they cannot be
mixed across sessions.  Also, it risks not being able to get on because it
has too many open channels.  Still it can behave that way.

Janifer

-----Original Message-----
From: Mark Needleman - DRA [mailto:[log in to unmask]]
Sent: Wednesday, 19 June 2002 19:27
To: [log in to unmask]
Subject: Re: is session id included in susequent request?


Ray

this seems to be a case of Reference Id in reverse and could be handled
the same way - if supplied by the server it must be returned by the
client?

mark


On Wed, 19 Jun 2002, Ray Denenberg wrote:

> The session id details seem mostly clear but
> there's one area I'm not clear about.
>
> When the server assigns a session id, does the
> client then include that id in subsequent requests
> within that session?
>
> I assumed yes, but I inferred from Rob (K) that it
> wasn't necessary. Maybe I mis-understood.
>
> Assuming so: If the client doesn't support (or
> care about) sessions, it won't include the session
> id.  And (I think we've decided) the client isn't
> going to request that a session id be assigned,
> the server will do that unilaterally. So when the
> server gets a request without a session id, it
> will assume a new session, and will assign a new
> session id, which the client won't use, etc. So
> the server will assign a bunch of session ids that
> won't be used. Is that a problem?  (In terms of
> wasted resources.)
>
> --Ray
>