Subject Re: two/more "non-conflicting" updates?
Author Olivier Mascia

On Sun, 04 Jan 2004 18:32:20 +0700,
David Garamond wrote:

> Currently, in FB, when a client (client #1) updates a row (and still
> hasn't finished his transaction), then client #2 which tries to update
> the same row will be rejected by FB.
> Suppose the update by client #1 is increasing the value of a numeric
> field by 1 (e.g. 5 becomes 6). And the client #2's udpdate is of the
> same operation. In other words, the two updates are non-conflicting.
> Both can be applied at whatever order and the effects are the same (I
> think the mathematical term is 'commutative'?)

This assumption would mean #2 read the updated value of #1 (or the
reverse) or that you have an kind of atomic operator (cross transactions)
that can actually increase a value.

See if using a generator for that numeric update is a good choice.

Best Regards,
Olivier Mascia