In Chango (my OODB vaporware) the default conflict semantics are that if 
any slot of an object is modified concurrently, you get a conflict.  
However, those semantics can be overridden by any class to implement 
concurrency semantics that reduce the risk of conflict.  You basically 
have to:

- describe how an object that is about to be modified gets copied for 
the transaction in which it is about to be modified
- implement a method that determines whether a given instance is in 
conflict with another
- implement a method to apply the changes in the modified object to the 
base object

The goal was to make a generalized framework where you could override 
the default concurrency semantics for any class.  Thus, you would not be 
restricted to just a few canned RC classes, but rather you could make 
more appropriate concurrency decisions at higher levels in your 
applications (you could define specialized concurrency semantics for 
your domain model classes for example).

Using this, I implemented a number of classes offering reduced conflict 
semantics, including the basics like a counter.

- Stephen

goran.krampe at bluefish.se wrote:

>Hi guys!
>
>I would intuitively had guessed that Magma has object locks (pessimistic
>concurrency) but I can't find it actually. The thing you are asking for
>(counters etc that can handle "physical" conflicts that aren't logical)
>is in GemStone called "reduced conflict" classes. I remember that it has
>rcCounter and rcSet for example with well defined semantics that you can
>follow.
>
>regards, Göran
>
>  
>