Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Jeremy Boynes" <jeremy@coredevelopers.net>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: Web Clustering : Stick Sessions with Shared Store
Date: Thu, 16 Oct 2003 14:07:15 -0700
Message-ID: <GHEHKNNAODAPCLJONCCDIEPDCPAA.jeremy@coredevelopers.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <EDDE2977F3D216428E903370E3EBDDC93E7064@MAIL01.stc.com>

> -----Original Message-----
> From: Andreas Schaefer [mailto:aschaefer@SeeBeyond.com]
> Sent: Thursday, October 16, 2003 12:59 PM
>
> Disadvantages
> 1. Need to write the session to the DB for every request.
>
>
> Awaiting comments.
> -hb
>
> [Andy]
>
> Now your DB becomes the single point of failure instead. Unless the DB
> is clustered, too, your synchronization will fail when the DB fails.
> AFAIK WebSphere is using or used this approach (for state replication)
> and that was in part a reason why it was/is so slow.
>

The system will typically have a hi-av database solution anyway otherwise
the DB will be a single point of failure for normal data storage (e.g. from
EJBs).

However, as Andy says, the cost of storing a serialized object in a BLOB is
significant. Other forms of shared store are available though which may
offer better performance (e.g. a hi-av NFS server).

The issue I have with hb's approach is the reliance on an Admin Server, of
which there would need to be at least two and they would need to co-operate
between themselves and with any load-balancers. I think this can be handled
by the regular servers themselves just as efficiently.

I am also not convinced it reduces the amount of net traffic. After each
request the MS must write to the shared store, which is the same traffic as
a unicast write to another node or a multicast write to the partition
(discounting the processing power needed to receive the message).

--
Jeremy