We initially used the IIS session state management exclusively but we began=
 to run into problems with some people who were surfing behind a proxy=
 (they all got the same session ID).  As well we use the Cisco Local=
 Director to do load balancing and if a users initial request went to=
 machine A and a subsequent request went to machine F then *sometimes* the=
 session ID would be lost.  In the end we ended up using the database to=
 generate unique ID's and stored them on the browser via the=
 request.querystring.  Each and every link and form contains this ID.  For=
 example:  <a href=3D"somepage.asp?id=3D<%=3D lngClientID %>">link</a>.=
  For redundancy we also store the ID in a cookie, but this cookie is=
 rarely, if ever, used.  Every page then does lngClientID =3D=
 Request.Querystring("id") and in the case where lngClientID =3D "" then we=
 check the cookie and if it is still null we get a new one from the=
 database. With this method we abandoned the IIS session state management=
 all together, which resulted in a great improvement in response time.

Make sense?



*********** REPLY SEPARATOR  ***********

On 11/8/2000 at 9:57 AM Rasika Wijayaratne wrote:

>I am just wondering what is the main difference in terms of
>implementation/use/performance when it comes to storing values in cookies=
 as
>oppossed to session variables.  I mean since cookies take up much less
>server resources it seesm to make sense to use cookies for all seesion=
 type
>tasks.  The only thing is that the code might be a couple of words longer,
>so its a bit of a hassle to write... annyone have any comments on this?

HWG: hwg-languages mailing list archives, maintained by Webmasters @ IWA