Shared Zones Discussion

All distributed shared zones will be pass by value. Every thread/process will get its own copy of the GC data stored in a particular zone. With this approach there is potential to incur blind writes.

Lets use a counter stored at ("/shared/counter") as an example. This counter is used by a 2 node application to count number of requests. Request thread increments the counter on every request.

Every thread is executing the following code def counter = zget ("/shared/counter"); counter++ zput ("/shared/counter", counter);

If the application is under light load, this could should work fine and report the correct number of total requests. If the load increases, the code may do blind write and the counter will not be correct.

Storing a version number with every key and tracking the versions as seen by individual threads will enable us detect a blind writes. if (readVersion (key) ! = currentVersion(key)) { throw BlindWriteException; }

When a user gets this exception, hse can analyze the code the know where it is. This type of optimistic locking is only useful if a retry is possible and has a good chance of success. Consider subversion commit operation that uses such locking. Since checking are not occurring continuously, a rare commit conflict can be resolved and the next check in usually succeeds.

If the chance of success on retry is low, then this type of locking cannot be used.

In case of global context, we cannot be certain that retry will succeed, hence we have to support locking.

Since Locking is a must for correct operation it remains questionable how much value versioning adds.

-- Mandar - 19 Aug 2008