Server Smalltalk Guide


Session management

Tip icon
To better understand this section, examine the sample SstHttpServerExample.

SST is not connection-oriented. It does not inherently supply application programmers with application-level notions of connected-ness. Connection-oriented transports such as TCP provide a sufficient basis of connection for some applications but not all. The HTTP client example explores this in more detail.

The number of design requirements and variations prevents us from building in a notion of application connection into the workings of SST. Instead we provide an external, configurable session management facility which you can incorporate into their applications.

Since connection is a user-defined concept, it is the user who must tell the session manager when a session starts and ends. The session manager simply maintains a set of session data (sessions) for the user. By default, a session has a named collection of arbitrary (user-defined) data. Sessions know their manager and can be opened and closed.

Given a set of information (for example, an incoming request), the session manager can resolve the session is it managing. The resolution strategy is defined by the class of session being used. For example, in the HTTP server example, the SstHttpSession resolution method does the following:

resolveSessionFor: request using: manager
   | cookie session httpRequest |
   "If the request already has a session then return it."
   (session := request session) notNil ifTrue: [^session].
   httpRequest := request arguments first.
   "Look for the cookie in the requests header and then search the
    session manager for the corresponding session."
   cookie := httpRequest header cookieFor: self cookieName.
   (cookie notNil and: [(session := manager sessionFor: cookie data) notNil])
      ifTrue: [
         request session: session.
         ^session].
   "No cookie found so if you can, auto generate a session and cookie."
   manager configuration autoGenerateSessions ifFalse: [^nil].
   (cookie := SstHttpCookie generateNew) name: self cookieName].
   (session := self for: manager)
      data: cookie;
      key: cookie data;
      open: request sender using: request remoteHandler.
   request header responseHeader at: HttpSetCookieKey add: cookie sstHttpString.
   manager open: session.
   request session: session.
   ^session

Given the current request, check to see if it already has a session assigned to it. If not, look in the request's header and see if there was a cookie supplied by the client. The cookie's data is used as the session key. If the manager has a session associated with that key, it is returned. At this point all possible avenues of obtaining pre-existing keys have been exhausted so a new session must be allocated if the session manager is configured to do this.

Since the session information is all user-defined, the HTTP cookie mechanism is used to generate a new cookie. Again, the cookie's data is used as the session key. Having created a new cookie, you create and initialize a new session.

If an HTTP server generates a cookie for a request which did not have one then the server should tag the request's response with the generated cookie value. Since the response has not yet been generated, the new cookie information is logged in the session's pending fields. These will be attached to the response when it is returned. Finally, the session is opened and attached to the current request.

During the processing of the request, application code can get access to the session by sending session to the current request. For example:

Processor sstCurrentRequest session.

Looking closely at the HTTP session you will note that it maintains a list of connections. These are the open connections related to the session. For example, a browser using frames will have a connection for each frame but all are part of the same session.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]