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).
[Matt]
Jeremy Boynes wrote:
-----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
