Enhance concurrency control section

[mmnosek]

Type of issue:

In concurrency control section of the page linked below, we use update (given 100, make two concurrent updates 110 and 120) to show the problem with concurrent updates. Then we ask the question what is the correct result, but there is no answer. This question shouldn't be left without the answer.

@k-rus @dan31 could you help us with the correct answer? Am I right that in this case transaction that tries to commit later won't be committed? Do we check conflicts with the transactions that are not yet committed? As far as I know, optimistic concurrency control will detect the conflict and rollback the transaction (which is the easiest way to resolve the conflict)

Do we have any other way of conflict resolution?

Link to relevant page:

https://docs.starcounter.io/guides/transactions/#concurrency-control

[k-rus]

To my knowledge when the later transaction gets conflict, it is retried and is committed if no new conflict happen. I don't work with concurrency control and cannot give more details. I believe @bigwad @eriohl or @chrhol can give more correct answer as they work more with this topic than me.

[eriohl]

We are using a classical snapshot isolation scheme meaning that if a record is updated within the a transaction is updated after the transaction started the transaction can't commit. Often referred to as "first committer wins". So if it end up 110 or 120 depends on which transaction commits first. The other one will be aborted.

This 130 implies that the transactions increases the current value by 10 or 20 respectively. So maybe this is what the documentation should say instead. If so the correct value is 130 which it will end up with it one of the aborted transaction is restarted. Which is the standard way of handling conflicts in optimistic concurrency control.

If the just set the value then it will be the value committed last, assuming this transaction is restarted. But I would argue that changing documentation to say increase would be better then trying to explain this because then there is a correct answer.

[eriohl]

Then if you involve this with long running transactions it gets kind of weird because long running transactions are kind of weird. In this case concurrency control is disabled on updates (so the last bit in the documentation mentioning these are a bit confusing). But maybe not mention this in this documentation because if then gets confusing and we are planning to drop long running transactions. Also: How the transaction is restarted and how many times are application or language binding specific so I would not go into this here either.

[eriohl]

Better to go into this with how it restarts on explaining transaction scopes I mean (which comes later).