Hello,

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 am 
not sure how one is supposed to solve with Magma - or simliar OO databases / 
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 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)?

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org