Normalt involverer løsningen på sådanne samtidighedsproblemer transaktioner og optimistisk låsning :Når du opdaterer tælleren, skal du tilføje en where klausul for at kontrollere den gamle værdi og tælle antallet af opdaterede rækker.
v = select value from counter where id=x.
update counter set value = v+1 where value = v and id=x
Hvis tælleren blev opdateret i mellemtiden, vil opdateringen ikke ændre nogen række – så du ved, at du skal rulle tilbage og prøve transaktionen en gang til.
Et problem er, at det kan føre til en høj strid , med kun få transaktioner, der lykkes, og mange, der mislykkes.
Så kan det være bedre at holde sig til pessimistisk låsning , hvor du låser rækken først og derefter opdaterer den. Men kun et benchmark vil fortælle dig.
REDIGER
Hvis du bruger transaktion uden optimistisk låsning, kan følgende scenarie ske.
Max authorized = 50. Current value = 49.
T1: start tx, read value --> 49
T2: start tx, read value --> 49
T1: update value --> 50, acquire a row lock
T1: commits --> release the lock
T2: update value --> 50, acquire a row lock
T2: commits --> release the lock
Begge transaktioner lykkes, værdien er 50, men der er en inkonsekvens.