Magma: Concurrent access to the same data
Chris Muller
afunkyobject at yahoo.com
Wed Oct 22 20:36:49 UTC 2003
> --- 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?
More information about the Squeak-dev
mailing list
|