True, Alex,
Let's number your suggestions 1,2,3 and look at them
(1) I call this one shared store. I think 'replication' is better than shared store for the following reasons :
- replication IS shared store, it's just the stores are in each and every node.
- because your store is already on-node, you save a round trip to the remote store with every request for a session
- replication allows your cluster to be made up of homogeneous nodes rather than heterogeneous ones (i.e. web servers and session servers) - clusters are complex enough already and a management nightmare. My aim is to make them easy, out-of-the box, deployments....
I shall probably end up implementing the replicated store as a separate Geronimo service anyway, so if you choose to deploy it seperately from the webcontainer you will effectively have the remote store that you are describing (this complicates deployment and logic since the load and functionality on/of a node now depend on it's type. There is no point in putting three webcontainers into a partition if they do not have a shared store between them and vice versa...)
(2) This is affinity/sticky sessions right ?
The one node holding the session becomes a SPoF for the client who owns the session. As soon as you add backing up the session off-node to the equation you are back at the replication (my approach) or shared store (1) approach. Except that you have the optimisation you describe in (3)??
(3) I'm not clear on exactly what is going on in this one :-) It looks like an optimisation (in the form of affinity) that you might use to prevent continually pulling the same unchanged session across a network from a shared store - right ? I will be doing exactly the same in my model. Mod_JK will be set up (dynamically and automagically) to route requests for sessions in particular bucket to ANY node in the partition in which the bucket resides. This is affinity at the partition level. I don't have to do it at the node level, since I can guarantee that the session is in-vm on every node in the partition. There is also, as far as i can tell, no way to tell Mod_JK to route to a node, but fail-over within a partition, at the moment. (Any mod_jk people reading this list ?).
So, actually, we are not far adrift :-) If you really like the DB idea, perhaps we could abstract away enough from what we are doing to allow a store to be a DB...
Jules
Alex Blewitt wrote:
There are a couple of other options than the one you list:
o Store all session state in a DB that's accessible by everyone (using Serialization and a blob)
o Keep the session on one machine, then forward all requests back to that one machine
o Try and forward requests to the same machine that had the session last time, or set up proxy (as above) dynamically
These approaches are likely to be more scaleable at the high-end than at the low-end. They do depend on a fast network between the servers, but in really serious server implementations I've worked on, they've had dedicated fast/gigabit networking just for the server/db machines.
Alex.
-- /************************************* * Jules Gosnell * Partner * Core Developers Network (Europe) * http://www.coredevelopers.net *************************************/
