> Interesting. Can you suggest a protocol we should use for > pessimistic distributed locking? I expect the cluster size to be > between 2-16 nodes with the sweet spot at 4 nodes. Each node will > be processing about 500-1000 tps and each tps will require on average > about 1-4 lock requests (most likely just one request for the web > session). Nodes should be able to join and leave the cluster easily.
If you must be a pessimist, then get shared locks for reads, exclusive locks for writes, two locks conflicting if at least one of them is an exclusive lock. Hold the locks acquired until after commit (strict 2pl). To get a lock you send a totem message and wait for it to arrive. A few ms. The latency for 4 nodes should be very respectable. For 16 nodes it might still be acceptable. I would measure the throughput/latency curve in your lab and based on that you can decide at what point you need something more sophisticated (which for me would be an independent replicated lock manager which can be reached through short tcp messages and some basic load balancing.) This paper actually shows some simulations of various concurrency control protocols, so you can make an educated decision: http://citeseer.ist.psu.edu/299097.html Guglielmo
