A couple of quick ones:
"Optimistic locking offers reduced concurrency..." - that should be "increased", right? And the other way around at: "Pessimistic locking increases concurrency...". Ah, I see you have a somewhat different definition of the word "concurrency" at http://minnow.cc.gatech.edu/squeak/2666 That might be confusing. As a sidenote GemStone sends "events" to the clients when they ought to "cross" as you call it. And if they don't follow that advice they are finally "forced to abort" or something like that I think.
Btw, at Swikipage 2639 " simulteneous indexes" should be "simultaneous indices". I think. :-) The page was locked so...
At page 2638 the "Two kinds of ReadStrategies" seems a bit incomplete. Perhaps you could proof read that again. In the example - where do you specify the instance variables and their levels?
If I am not mistaken there is also another "nitpicky" variant of conflict that I assume you have ignored - if transaction A reads object foo that has been changed by transaction B after A started. I believe GemStone calls that a "read conflict" or something. The idea being that logically transactions "occur in full" at the time of their commit and transaction A should not be permitted to depend on a "stale" value in foo.
IIRC GemStone has some kind of "full checks" or something that you can turn on when deploying to enable this nitpickyness.
Whatever, just thinking aloud. :-)
...ok, now I have read through all swiki pages I could find and darn - this sounds pretty great! Actually if it is as good as it sounds :-) it is one of the most exciting things in Squeak for a loooong time! I am ecstatic. Hmmm, I will look into perhaps using this for SqueakMap...
Ah, now I just read about the license! Good. I sortof gathered that since you have used the Swiki to document it. :-)
regards, Göran
squeak-dev@lists.squeakfoundation.org