> --- In squeak at yahoogroups.com, Peter Schüller <peter.schuller at i...>
> wrote:
> ...
> When there is a conflict during a commit (i.e., someone else changed
> the data
> first), a MagmaCommitError is raised. This is fine when there is
> a "real"
> conflict at the application layer (such as two people simultaneously
> modifying the description of an object). However, there are instances
> where
> conflicts are *expected*. Or rather, where one would, in a multi-
> threaded
> situation, use a semaphore/lock to control access to critical data.
> 
> Examples include:
> 
> * Incrementing a value (x := x + 1, where x is persistent)
> * Adding an object to a Collection (not a MagmaCollection)
> * Creating a shared resource on demand
> 
> Examples (contrived, obviously):
> 
> session commit: [
> 	"Assuming there is no need to index relationships:"
> 	person friends addLast: newFriend.
> ].
> 
> And concurrently on another client:
> 
> session commit: [
> 	person friends remove: previousFriend.
> ].
> 
> Assuming newFriend is not referencing the same object as
> previousFriend, the
> two actions are not "really" in conflict; one would not want to have
> to retry
> such an operation due to the modification of the same Collection for
> unrelated reasons.
> 
> Another example would be maintaining, for example, a counter for the
> total
> number of, say, employees who have ever worked at a company (without
> maintaining the actual list of employees). How can I increment such a
> counter
> without causing a conflict if two employees happen to be added to the
> database almost at the same time (which, at the
> application/problem/user
> level is not a conflicting action)?

Hi Peter, Avi, Göran!

Magma does not support pessimistic locking.  Those are some good examples,
however, I don't know a way to implement pessimistic locking without tripling
the complexity (and likely reducing performance) of the code.  It seems to
introduce a whole boatload of problems for a "real-time" database.  GemStone's
user manual seems to strongly discourage using pessimistic.

One of the purposes of MagmaCollections was reduced-concurrency.  So that
leaves the counter example.  Hmm..  As an alternative to a rcCounter
equivalent, I wonder whether it would be possible to "simulate" pessimistic
locking by using a while loop or the #retry of Squeaks awesome Exceptions. 
Something like:

    [ mySession commit: [ x := x + 1 ] ]
      on: MagmaCommitError
      do: [ : err | err retry ]

Göran mentioned the rcCollections in GemStone.  A problem with those guys
though is they need indexes to be effective and, guess what, the indexes are
not reduced-conflict, so you end up with a commit failure anyway.

Or perhaps, implementing something like an rcCounter could be done with much
less cost than full pessimistic locking.  I already implemented my own
"rcCollection" (a.k.a., MagmaCollection) I would think the rcCounter could be
done more easily.

Would that solve most of your desire for pessimistic?