geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bhagwat, Hrishikesh" <>
Subject RE: Web Clustering : Stick Sessions with Shared Store
Date Fri, 17 Oct 2003 01:45:38 GMT
Comments embeded as [HB - x ]

- hb

> 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).

[ HB -1 ] yep .. i agree .. if the DB goes down there is any ways NO business !

> 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).

[ HB -2 ] What about the failover of the NFS. The comment "HB-1" above 
and "Jeremy's original comment" about failover of the DB cannot be applied 
to NFS (not much experience with NFS .. just thinking aloude ..pls correct
me if i am wrong on this ). What I mean is that though its a hi-av server 
the possibility exists that all the MS and the DB (storing the business data) 
are available but the NFS is not .. thus bringing the system to a halt (even though 
all the business related components/servers are ok) then, i think DB 
might still be a good option. About BLOB we could always store the Session object 
by (as they say in section 1.1.1) by "intelligently reading the contents of the 
session and writing it out field-by-field"

> 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.

[ HB -3 ] ya i guess i made a little mistake there by calling that entity
an admin server. The admin server that's shown in the figure is really just
a load-balancer and little more. We can certainly go the Jeremy's way.

> 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).

[ HB -4 ] I think this is a point where we need to either carry out real tests
in a lab or check for general statistics lying around on the net... will investigate
and collect more stats.

> --
> Jeremy

View raw message