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