geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Humphrey <>
Subject Re: Web Clustering : Stick Sessions with Shared Store
Date Fri, 17 Oct 2003 12:04:54 GMT
Excuse me for butting in here, but I have two comments:

1. You only need to update the database when the session changes. In a 
typical web application, updates to session data are much less frequent 
than reads.

2. Would it be possible to achieve the same results without an Admin 
server? The Admin server seems like a single point of failure in your 
design (or perhaps you meant for there to be at least two admin servers).


Jeremy Boynes wrote:

>>-----Original Message-----
>>From: Andreas Schaefer []
>>Sent: Thursday, October 16, 2003 12:59 PM
>>1. Need to write the session to the DB for every request.
>>Awaiting comments.
>>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
>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).

View raw message