Andy Piper wrote:
Hi Filip
At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
Burning a primary-secondary scheme into the API seems a little less
general. I think you should assume there can be N backups, where N is
usually 1. How do you handle locking with this API?
we already have an all-to-all implementation, this is just another
implementation. but it is true, maybe there should be more than one
backup, I'll start with one, and move to more than one if needed. In
terms of locking, none planned, to much overhead.
correctness can be achieved within the session itself, ie if it is
getting serialized, it would need to lock itself and then reset its
state for the next diff. sessions today have access counters, which
means that we can also periodically solicit sessions that are not being
accessed at the time, and not worry about the locks at all.
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry
combinations in their session map. But only two nodes will have the
actual data.
This solution is for sticky LB only, but when failover happens, the
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new
one, and do a publish to the entire cluster of the locations.
Doesn't this mean you have to publish to the whole cluster at session
creation? This will eventually limit scalability IMO.
as mentioned earlier, for very large clusters, we can use a Cookie to
store the backup location, this is the solution to your concern about
broadcasting the map each time. although, other challenges arise with
this. but I plan on having both solutions.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
