On Tue, 21 Oct 2003, Peter [iso-8859-1] Sch=FCller wrote:

> I have been toying with magma off and on for a while now, and I like it a=
 lot
> for obvious reasons (transparency!). There is one problem though that I a=
m
> not sure how one is supposed to solve with Magma - or simliar OO database=
s /
> persistence layers in general.
>
> 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 whe=
re
> 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 :=3D x + 1, where x is persistent)
> * Adding an object to a Collection (not a MagmaCollection)
> * Creating a shared resource on demand

Normally this is solved with per-object locks, so that this would look
very much like using a semaphore (except that the semaphore is managed by
a central server, and the threads waiting on it may be distributed over
many machines).  I don't know if Magma supports this.  My initial work on
a Squeak interface to GOODS (a similar but language-neutral OODB) does.
I'm still waiting for some project or client to need GOODS so that I can
put more time into working on it :).

Avi