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