Optimistische gelijktijdigheid

Optimistische gelijktijdigheid leidt zijn naam af van de optimistische veronderstelling dat conflicten tussen transacties zelden optreden; er wordt gezegd dat er een botsing is opgetreden wanneer een andere transactie een rij gegevens bijwerken of verwijdert tussen de tijd die wordt gelezen door de huidige transactie en het tijdstip waarop deze wordt bijgewerkt of verwijderd. Het is het tegenovergestelde van pessimistische gelijktijdigheid of vergrendeling, waarbij de toepassingsontwikkelaar ervan uitgaat dat dergelijke conflicten vaak voorkomen.

Bij optimistische concurrentie wordt een rij ongelockt gehouden totdat het tijd is om deze bij te werken of te verwijderen. Op dat moment wordt de rij opnieuw gelezen en gecontroleerd of deze is gewijzigd sinds de laatste leesbewerking. Als de rij is gewijzigd, mislukt de update of het verwijderen en moet het opnieuw worden geprobeerd.

Om te bepalen of een rij is gewijzigd, wordt de nieuwe versie gecontroleerd op een versie in de cache van de rij. Deze controle kan worden gebaseerd op de rijversie, zoals de tijdstempelkolom in SQL Server of de waarden van elke kolom in de rij. Veel DBMS'en ondersteunen geen rijversies.

Optimistische gelijktijdigheid kan worden geïmplementeerd door de gegevensbron of de toepassing. In beide gevallen moet de toepassing een laag isolatieniveau voor transacties gebruiken, zoals Read Committed; als u een hoger niveau gebruikt, gaat de gewonnen gelijktijdigheid door het gebruik van optimistische gelijktijdigheid verloren.

Indien optimistische gelijktijdigheid via de gegevensbron wordt geïmplementeerd, stelt de toepassing de instructie-eigenschap SQL_ATTR_CONCURRENCY in op SQL_CONCUR_ROWVER of SQL_CONCUR_VALUES. Om een rij bij te werken of te verwijderen, wordt er een positioned update- of delete-instructie uitgevoerd of SQLSetPos wordt aangeroepen zoals het zou zijn met pessimistische gelijktijdigheid; retourneert het stuurprogramma of de gegevensbron SQLSTATE 01001 (conflict met cursorbewerking) als de update of het verwijderen mislukt vanwege een botsing.

Als de toepassing zelf optimistische gelijktijdigheid implementeert, stelt het de instructieattribuut SQL_ATTR_CONCURRENCY in op SQL_CONCUR_READ_ONLY om de rij te lezen. Als rijversies vergeleken moeten worden en de kolom rijversie niet bekend is, wordt SQLSpecialColumns aangeroepen met de optie SQL_ROWVER om de naam van deze kolom te bepalen.

De toepassing werkt de rij bij of verwijdert deze door de gelijktijdigheid te verhogen naar SQL_CONCUR_LOCK (om schrijftoegang tot de rij te krijgen) en door een UPDATE - of DELETE-instructie uit te voeren met een WHERE-component die de versie of waarden aangeeft die de rij had toen de toepassing deze las. Als de rij sindsdien is gewijzigd, mislukt de statement. Als de WHERE-component de rij niet uniek identificeert, kan de instructie ook andere rijen bijwerken of verwijderen; rijversies identificeren altijd unieke rijen, maar rijwaarden identificeren alleen rijen als ze de primaire sleutel bevatten.