Nick Bauman wrote:
> Jason,
>
>> Yes, and the way I've seen people solve this issue is to make each
>> server constantly replicate its sessions to another server so that any
>> session's state is stored in two servers (not just one). For example,
>> if you've got four servers, A, B, C, and D, you configure A to
>> replicate to B, B to replicate to C, C to replicate to D, and D to
>> replicate to A. Then the "composite ID" would contain the primary
>> server tag, secondary server tag, and the session ID, like:
>> A:B:sessionXXX. So, if server A went down, the load balancer could
>> still get session info from server B, and at the same
>> time let server D know that A is down and to replicate to B until
>> further notice.
>
>
> Naaaah.
>
> This is once again only making sure a majority of the sessions are saved in
> a rotation. A lot of work for very little real fault tolerance.
Sorry to say, but the folks at BEA disagree with you -- this is exactly
what Weblogic does to facilitate distributed HTTP sessions. In-memory
replication to a selected "buddy" server is pretty fast and fault tolerant
enough for most failures. It can also ensure no single point of failure.
> Also I think your english up there indicates a solution that causes
> tremendous hysterysis amongst the servers.
How so?
>> This also works when each server replicates sessions to more than one
>> backup server so that you've got even higher fault tolerance (but
>> you'll probably never need that level of fault tolerance).
>
>
> Now you may have something: a seperate, parallel, session cluster.
Anyone could sure do it that way. But, I'm not sure that separating it
out from the servers themselves could add much fault tolerance since
the cons to doing this seem to be about as large as the pros. It seems to
me that making it part of the servers (the servlet containers, for instance)
would work just as well.
--
Jason Brittain
Software Engineer, Olliance Inc. http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
