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.
Also I think your english up there indicates a solution that causes
tremendous hysterysis amongst the servers.
> 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.
> --
> Jason Brittain
--
Nick Bauman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
