Re: Session Affinity

Mark Brown (
Tue, 13 Aug 1996 16:16:38 -0400

Message-Id: <>
Subject: Re: Session Affinity 
In-Reply-To: <> 
Date: Tue, 13 Aug 1996 16:16:38 -0400
From: Mark Brown <>

Oliver Lavery asks:

    I'm looking at developing a few FastCGI apps in C++, and
    was wondering if anyone had experience with session affinity
    (which doesn't seem to be covered in depth in the documentation)

Session affinity is covered in the Open Market Secure WebServer v2.0
documentation.  The Apache and NCSA servers do not provide session
affinity at this time.  If you don't have an OM-SWS v2.0, please
download a free eval to obtain the documentation.

The sample-store application in the FastCGI developer's kit
(examples/sample-store.c) demonstrates the use of session affinity.

    - if an app using session affinity is run as several processes,
      will each session _always_ be routed to the same process?

Yes.  Of course, if a process dies and is restarted, the replacement
process will get the next request.  These processes "know" their
identity via a variable in the inital environment, FCGI_PROCESS_ID.

    - is there any maximum on the number of session which can be handled
      by a process?


    - how is the uid (or whatever) for the session determined ... one
      of the examples listed several different methods, but are they
      configuration options or can determining the uid be handled by
      an Authorizer app or something of the like?

Default session affinity uses the session ID capability built into the
OM-SWS.  Session IDs can be generated on the Web server or on an
associated OM-Axcess server.  See Chapter 7 of the OM-SWS v2.0 doc.

The AffinityMap directive allows you to use whatever session ID you
like.  For instance, if your scripts encode custom session IDs into
your URLs, you'd write a decode procedure in Tcl and use it to extract
the session ID and hand it over to AffinityMap.  Or you can write the
decode procedure in C and invoke it as a FastCGI Authorizer, having it
return the extracted session ID.

If session IDs are only embedded into certain URLs that can be
specified by simple patterns, you can avoid the overhead of looking
for a session ID in URLs that don't contain them.

Normally the session ID is treated as a string that's hashed down to
produce the ID of the process to call.  The AffinityMap -id option
allows you to specify the process ID instead, giving complete control
over the distribution of requests to processes.

See the AppClass and AffinityMap directives described in the OM-SWS
v2.0 doc for more information.

    My other question concerned threading ... I'm using Oracle, and
    was wondering if I could safely use two threads, one to handle
    FastCGI requests, and the other to write information accumulated
    from the requests into Oracle (in the background).

Your design should work fine as long as the background thread does not
call any FastCGI procs or access the standard I/O streams.