"Alex Adriaanse" <alex@alexandcarmen.com> writes
> Applying this analogy to our database, wouldn't that require a
> table-level lock during a CVS-like commit (which would mean locking the
> table, getting the revision number, updating the row(s), and committing
> the transaction)?
>
You may have a look at how CVS works and decide it. Note the difference is
that CVS manages the files and versions, and seems you just manage the
versions?
Another way is to change the logic - try to submit the update together.
Think the bank-transfer example we always used in describing transaction's
atomic property, which shares something common in your case. We fold the
logic of reduce some money and add some money together, so no matter how
many concurrent transfer is on the target account, it is guarantteed no race
condition, since the "serializable" property assures that.
Regards,
Qingqing
