The spec allows for web servers to exchange session state. To do this you
need to mark your app as distributable, and make sure everything in the
session is serializable. In all honesty (and I stand to be corrected) I'm
not sure how many servers will implement this for load balancing. It just
strikes me as being too expensive.
One solution is to store the data in another server (usually a database) and
keep a cached local copy on each server in the farm. Along with the cookie
pass a timestamp so that you know if the cache is still valid. On each
intitial hit to a server you retrieve the state from the DB and so incur a
roundtrip, on subsequent hits you may incur a roundtrip depending on the
state of the cache.
Using the cache may or may not be a good idea depending on you usage
profile. If the session is usually read, then the cache is a good idea. If
you do lots of writes then the cache will just slow things down.
Kevin Jones
DevelopMentor
www.develop.com
> -----Original Message-----
> From: Ferguson, Doug [mailto:[EMAIL PROTECTED]]
> Sent: 31 January 2001 15:35
> To: '[EMAIL PROTECTED]'
> Subject: session variables in a server farm
>
>
> Is there an elegant way to implement session variables in a load balancing
> senario? If I understand correcty everything is stored on the
> server and a sessionID is store in the users browser so that the
> server can look it up. But what happens when the user gets routed
> to another server which doesn't have their info stored in the session,
> we wouldn't want them to log in again. We though about placing this
> info in our ejb layer. But we'd like to not have to do a remote call
> just for authentication purposes.
>
> d.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
