I have a numeric field. Users will modify it by adding a value to it.

But I'm a little concerned about the unlikely event where two users are
incrementing it at the same time. Unless there is some sort of lock between
the time the old value is read and the sum of the two values is written, one
change could override another.

Any suggestions?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Assuming you are using some sort of database, mark the transaction as
serializable and include a WHERE clause with the old value.

"Jonathan Wood" <jwood (AT) softcircuits (DOT) com> wrote

Jonathan,

I don't understand how this particular example would need to be handled any
differently than your normal concurrency handling.

Kerry Moorman


"Jonathan Wood" wrote:

If I want to set a field to a specific value, I can just set it. If it
overrides another update, that's fine because someone set the value after
someone else.

On the other hand, if I want to increment a value, say, 10, it's possible
that two users read the old value, the first one writes an 11 and then the
second one writes an 11. In this case, the second update was not an
increment, as expected.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Kerry Moorman" <KerryMoorman (AT) discussions (DOT) microsoft.com> wrote

Yes, of course it would just fail then if the WHERE didn't match.

Could I trouble you to explain the advantage of marking the transaction as
serializable?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Jim Rand" <jimrand (AT) ix (DOT) netcom.com> wrote

Jonathan,

So you are saying that you generally handle concurrency with the "last in
wins" strategy?

Kerry Moorman


"Jonathan Wood" wrote:

Kerry,

Why not? If someone wants to set a field to one value, and someone later
wants to set it to another (even if only milliseconds later), why should I
prevent the field from being changed just because it had been changed
earlier?

Jonathan

Jonathan,

The safest, create an extra (child) table where in you keep the mutations.
The sum of those is than the value of the field.
AFAIK you have In fact than never a concurrency problem because it are all
new inserted rows.

Cor