Subject | Re: two/more "non-conflicting" updates? |
---|---|
Author | Olivier Mascia |
Post date | 2004-01-04T13:33:47Z |
Hello,
On Sun, 04 Jan 2004 18:32:20 +0700,
David Garamond wrote:
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
On Sun, 04 Jan 2004 18:32:20 +0700,
David Garamond wrote:
> Currently, in FB, when a client (client #1) updates a row (and stillThis assumption would mean #2 read the updated value of #1 (or the
> 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'?)
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