> -----Original Message----- > From: Andreas Schaefer [mailto:[EMAIL PROTECTED] > 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
