Optimistisk samtidighetskontroll

Optimistisk samtidighetskontroll ( OCC ), även känd som optimistisk låsning , är en metod för samtidighetskontroll som tillämpas på transaktionssystem som hanteringssystem för relationsdatabas och transaktionsminne för programvara . OCC antar att flera transaktioner ofta kan genomföras utan att störa varandra. Under körning använder transaktioner dataresurser utan att låsa dessa resurser. Innan den genomförs verifierar varje transaktion att ingen annan transaktion har ändrat den information den har läst. Om kontrollen avslöjar motstridiga ändringar, rullar den genomförande transaktionen tillbaka och kan startas om. Optimistisk samtidighetskontroll föreslogs först av HT Kung och John T. Robinson.

OCC används vanligtvis i miljöer med låg datakonflikt . När konflikter är sällsynta kan transaktioner slutföras utan kostnaden för att hantera lås och utan att transaktioner väntar på att andra transaktioners låsningar ska rensas, vilket leder till högre genomströmning än andra metoder för samtidighetskontroll. Men om konflikten om dataresurser är frekvent, skadar kostnaden för att upprepade gånger omstarta transaktioner prestandan avsevärt, i vilket fall andra för samtidighetskontroll kan vara bättre lämpade. Låsningsbaserade ("pessimistiska") metoder kan emellertid också ge dålig prestanda eftersom låsning drastiskt kan begränsa effektiv samtidighet även när dödlägen undviks.

Faser av optimistisk samtidighetskontroll

Optimistiska transaktioner för samtidighetskontroll involverar dessa faser:

  • Börja : Spela in en tidsstämpel som markerar transaktionens början.
  • Ändra : Läs databasvärden och skriv preliminärt ändringar.
  • Validera : Kontrollera om andra transaktioner har modifierade data som denna transaktion har använt (läst eller skrivit). Detta inkluderar transaktioner som slutförts efter denna transaktions starttid, och eventuellt transaktioner som fortfarande är aktiva vid valideringstillfället.
  • Commit/Rollback : Om det inte finns någon konflikt, låt alla ändringar träda i kraft. Om det finns en konflikt, lös den, vanligtvis genom att avbryta transaktionen, även om andra lösningssystem är möjliga. Försiktighet måste iakttas för att undvika en tid-för-kontroll till tid-för-användning bugg, särskilt om denna fas och den föregående inte utförs som en enda atomär operation.

Webbenvändning

HTTPs tillståndslösa karaktär gör låsning omöjlig för webbanvändargränssnitt . Det är vanligt att en användare börjar redigera en post och sedan lämnar utan att följa en "avbryt" eller "logga ut"-länk. Om låsning används måste andra användare som försöker redigera samma post vänta tills den första användarens låsning går ut.

HTTP tillhandahåller en form av inbyggd OCC. Svaret på en initial GET-förfrågan kan inkludera en ETag för efterföljande PUT-förfrågningar att använda i If-Match-huvudet. Alla PUT-förfrågningar med en inaktuell ETag i If-Match-huvudet kan sedan avvisas.

Vissa databashanteringssystem erbjuder OCC inbyggt, utan att kräva speciell applikationskod. För andra kan applikationen implementera ett OCC-lager utanför databasen och undvika att vänta eller tyst skriva över poster. I sådana fall formuläret innehålla ett dolt fält med postens ursprungliga innehåll, en tidsstämpel, ett sekvensnummer eller en ogenomskinlig token. Vid inlämning jämförs detta med databasen. Om den skiljer sig anropas konfliktlösningsalgoritmen.

Exempel

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Optimistic_concurrency_control&oldid=1091159570 "