Samtidighetskontroll

Samtidighet är möjligheten för två transaktioner att använda samma data samtidigt, och med ökad transaktionsisolering kommer vanligtvis minskad samtidighet. Detta beror på att transaktionsisolering vanligtvis implementeras genom att låsa rader, och när fler rader är låsta kan färre transaktioner slutföras utan att blockeras åtminstone tillfälligt av en låst rad. Även om minskad samtidighet är allmänt accepterad som en kompromiss för de högre transaktionsisoleringsnivåer som krävs för att upprätthålla databasintegriteten, kan det bli ett problem i interaktiva program med hög läs-/skrivaktivitet som använder markörer.

Anta till exempel att ett program kör SQL-instruktionen SELECT * FROM Orders. Den anropar SQLFetchScroll för att rulla runt resultatuppsättningen och låter användaren uppdatera, ta bort eller infoga beställningar. När användaren har uppdaterat, tagit bort eller infogat en order bekräftar programmet transaktionen.

Om isoleringsnivån är Repeterbar läsning kan transaktionen , beroende på hur den implementeras, låsa varje rad som returneras av SQLFetchScroll. Om isoleringsnivån är Serializable kan transaktionen låsa hela tabellen Beställningar. I båda fallen släpper transaktionen sina lås endast när den bekräftas eller återkallas. Så om användaren ägnar mycket tid åt att läsa beställningar och mycket lite tid på att uppdatera, ta bort eller infoga dem kan transaktionen enkelt låsa ett stort antal rader, vilket gör dem otillgängliga för andra användare.

Det här är ett problem även om markören är skrivskyddad och programmet endast tillåter användaren att läsa befintliga beställningar. I det här fallet checkar programmet in transaktionen och släpper lås när den anropar SQLCloseCursor (i automatiskt incheckningsläge ) eller SQLEndTran (i manuellt incheckningsläge).

Det här avsnittet innehåller följande avsnitt.

• Samtidighetstyper

• Optimistisk samtidighet