DBMS samtidighetskontroll: tidsstämpel och låsbaserade protokoll

Samtidig åtkomst är ganska lätt om alla användare bara läser data. Det finns inget sätt att de kan störa varandra. Även om den för vilken praktisk databas som helst skulle ha en blandning av LÄS- och SKRIV-operationer och därför är samtidigheten en utmaning.

DBMS Concurrency Control används för att hantera sådana konflikter, som oftast uppstår med ett fleranvändarsystem. Därför är Concurrency Control det viktigaste elementet för att ett databashanteringssystem ska fungera korrekt där två eller flera databastransaktioner exekveras samtidigt, vilket kräver åtkomst till samma data.

Potentiella problem med samtidighet

Här är några problem som du sannolikt kommer att möta när du använder DBMS Concurrency Control-metoden:

• Förlorade uppdateringar uppstår när flera transaktioner väljer samma rad och uppdaterar raden baserat på det valda värdet
• Oengagerade beroendeproblem uppstår när den andra transaktionen väljer en rad som uppdateras av en annan transaktion (smutsig läsning)
• Ej upprepningsbar läsning inträffar när en andra transaktion försöker komma åt samma rad flera gånger och läser olika data varje gång.
• Felaktigt sammanfattningsproblem inträffar när en transaktion tar sammanfattningen över värdet av alla instanser av en upprepad datapost, och den andra transaktionen uppdaterar några få instanser av den specifika dataposten. I den situationen återspeglar den resulterande sammanfattningen inte ett korrekt resultat.

Varför använda Concurrency-metoden?

Anledningar till att använda metoden för samtidighetskontroll är DBMS:

• Att tillämpa isolering genom ömsesidig uteslutning mellan motstridiga transaktioner
• För att lösa läs-skriva och skriv-skriv konfliktproblem
• Att bevara databasens konsistens genom att ständigt bevara exekveringshinder
• Systemet behöver kontrollera interaktionen mellan de samtidiga transaktionerna. Denna kontroll uppnås med hjälp av samtidiga kontrollscheman.
• Samtidighetskontroll hjälper till att säkerställa serialisering

Exempelvis

Antag att två personer som går till elektroniska kiosker samtidigt för att köpa en biobiljett till samma film och samma visningstid.

Det finns dock bara en plats kvar för filmshowen på just den teatern. Utan samtidighetskontroll i DBMS är det möjligt att båda biobesökarna kommer att köpa en biljett. Men samtidighetskontrollmetoden tillåter inte att detta händer. Båda biobesökarna kan fortfarande komma åt information skriven i databasen för filmplatser. Men samtidighetskontroll ger bara en biljett till köparen som har slutfört transaktionsprocessen först.

Protokoll för samtidighetskontroll

Olika protokoll för samtidighetskontroll erbjuder olika fördelar mellan mängden samtidighet de tillåter och mängden omkostnader som de medför. Följande är teknikerna för samtidighetskontroll i DBMS:

• Låsbaserade protokoll
• Tvåfaslåsningsprotokoll
• Tidsstämpelbaserade protokoll
• Valideringsbaserade protokoll

Ett lås är en datavariabel som är associerad med en datapost. Detta lås betyder att operationer som kan utföras på dataobjektet. Lås i DBMS hjälper till att synkronisera åtkomst till databasobjekten genom samtidiga transaktioner.

Alla låsförfrågningar görs till samtidighetskontrollhanteraren. Transaktioner fortsätter först när låsbegäran har beviljats.

Binära lås: Ett binärt lås på ett dataobjekt kan antingen vara låst eller olåst.

Delat/exklusivt: Denna typ av låsmekanism separerar låsen i DBMS baserat på deras användningsområden. Om ett lås förvärvas på ett dataobjekt för att utföra en skrivoperation, kallas det ett exklusivt lås.

1. Delat lås (S):

Ett delat lås kallas även ett skrivskyddat lås. Med det delade låset kan dataposten delas mellan transaktioner. Detta beror på att du aldrig kommer att ha behörighet att uppdatera data på dataobjektet.

Tänk till exempel på ett fall där två transaktioner läser en persons kontosaldo. De databas låter dem läsa genom att placera ett delat lås. Men om en annan transaktion vill uppdatera kontots saldo, förhindrar delat lås det tills läsningsprocessen är över.

2. Exklusivt lås (X):

Med det exklusiva låset kan en datapost läsas och skrivas. Detta är exklusivt och kan inte hållas samtidigt på samma dataobjekt. X-lås begärs med lås-x instruktion. Transaktioner kan låsa upp dataobjektet efter att ha avslutat "skriv"-operationen.

Till exempel när en transaktion behöver uppdatera kontosaldot för en person. Du kan tillåta denna transaktion genom att placera X-lås på den. Därför, när den andra transaktionen vill läsa eller skriva, förhindrar exklusiv lås denna operation.

3. Simplistic Lock Protocol

Denna typ av låsbaserade protokoll tillåter transaktioner att erhålla ett lås på varje objekt innan operation påbörjas. Transaktioner kan låsa upp dataposten efter att ha avslutat "skriv"-operationen.

4. Föranmälan Låsning

Föranspråkslåsprotokoll hjälper till att utvärdera operationer och skapa en lista över nödvändiga dataobjekt som behövs för att initiera en exekveringsprocess. I situationen när alla lås är beviljade, genomförs transaktionen. Efter det släpps alla lås när alla dess operationer är över.

Svält

Svält är situationen när en transaktion måste vänta på obestämd tid för att få ett lås.

Följande är anledningarna till svält:

• När man väntar är schemat för låsta föremål inte korrekt hanterat
• Vid resursläckage
• Samma transaktion väljs ut som ett offer upprepade gånger

Dödläge

Deadlock hänvisar till en specifik situation där två eller flera processer väntar på att varandra ska släppa en resurs eller mer än två processer väntar på resursen i en cirkulär kedja.

Detta låsprotokoll delar upp exekveringsfasen av en transaktion i tre olika delar.

• I den första fasen, när transaktionen börjar utföras, kräver den tillstånd för de lås den behöver.
• Den andra delen är där transaktionen får alla lås. När en transaktion släpper sitt första lås, startar den tredje fasen.
• I denna tredje fas kan transaktionen inte kräva några nya lås. Istället släpper den bara de förvärvade låsen.

Tvåfaslåsningsprotokollet tillåter varje transaktion att göra en begäran om låsning eller upplåsning i två steg:

• Växande fas: I denna fas kan transaktion erhålla lås men kanske inte släppa några lås.
• Krympningsfas: I denna fas kan en transaktion släppa lås men inte få något nytt lås

Det är sant att 2PL-protokollet erbjuder serialiserbarhet. Det säkerställer dock inte att dödlägen inte inträffar.

I det ovan givna diagrammet kan du se att lokala och globala dödlägesdetektorer söker efter dödlägen och löser dem genom att återuppta transaktioner till sina initiala tillstånd.

Strikt tvåfaslåsningsmetod

Strict-Two-fas låssystem är nästan likt 2PL. Den enda skillnaden är att Strict-2PL aldrig släpper ett lås efter att ha använt det. Den håller alla lås till commit-punkten och släpper alla lås på en gång när processen är över.

Centraliserad 2PL

I Centralized 2 PL är en enda plats ansvarig för låshanteringsprocessen. Den har bara en låshanterare för hela DBMS.

Primär kopia 2PL

Primär kopia 2PL-mekanism, många låshanterare distribueras till olika platser. Därefter är en viss låshanterare ansvarig för att hantera låset för en uppsättning dataobjekt. När den primära kopian har uppdaterats sprids ändringen till slavarna.

Distribuerad 2PL

I denna typ av tvåfas låsmekanism distribueras låshanterare till alla platser. De är ansvariga för att hantera lås för data på den platsen. Om ingen data replikeras motsvarar den primärkopia 2PL. Kommunikationskostnaderna för distribuerad 2PL är ganska högre än primärkopia 2PL

Den äldre transaktionen prioriteras alltid i denna metod. Den använder systemtid för att fastställa transaktionens tidsstämpel. Detta är det vanligaste samtidighetsprotokollet.

Låsbaserade protokoll hjälper dig att hantera ordningen mellan de motstridiga transaktionerna när de ska köras. Tidstämpelbaserade protokoll hanterar konflikter så snart en operation skapas.

Exempelvis:

Suppose there are there transactions T1, T2, and T3. 
T1 has entered the system at time 0010 
T2 has entered the system at 0020
T3 has entered the system at 0030
Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

Fördelar:

• Scheman kan serialiseras precis som 2PL-protokoll
• Ingen väntan på transaktionen, vilket eliminerar möjligheten till dödlägen!

Nackdelar:

Svält är möjligt om samma transaktion startas om och ständigt avbryts

Det valideringsbaserade protokollet utförs i följande tre faser:

1. Läs Fas
2. Valideringsfas
3. Skriv Fas

Läs Fas

I läsfasen kan datavärdena från databasen läsas av en transaktion men skrivoperationen eller uppdateringarna tillämpas endast på de lokala datakopiorna, inte den faktiska databasen.

Valideringsfas

I valideringsfasen kontrolleras data för att säkerställa att det inte finns någon kränkning av serialiseringsbarheten när transaktionsuppdateringarna tillämpas på databasen.

Skriv Fas

I skrivfasen tillämpas uppdateringarna på databasen om valideringen lyckas, annars; uppdateringarna tillämpas inte och transaktionen återställs.

Egenskaper för Good Concurrency Protocol

En idealisk DBMS-mekanism för samtidighetskontroll har följande mål:

• Måste vara motståndskraftig mot webbplats- och kommunikationsfel.
• Det möjliggör parallellt genomförande av transaktioner för att uppnå maximal samtidighet.
• Dess lagringsmekanismer och beräkningsmetoder bör vara blygsamma för att minimera omkostnader.
• Det måste upprätthålla vissa begränsningar för strukturen av atomära åtgärder av transaktioner.

Sammanfattning

• Samtidighetskontroll är proceduren i DBMS för att hantera samtidiga operationer utan att komma i konflikt med varandra.
• Förlorade uppdateringar, smutsig läsning, icke-repeterbar läsning och felaktigt sammanfattningsproblem är problem som uppstår på grund av bristande samtidighetskontroll.
• Låsbaserad, tvåfasig, tidsstämpelbaserad, valideringsbaserad är typer av samtidighetshanteringsprotokoll
• Låset kan vara delat (S) eller exklusivt (X)
• Tvåfaslåsningsprotokoll som också är känt som ett 2PL-protokoll behöver transaktion bör få ett lås efter att det släpper ett av sina lås. Den har 2 faser som växer och krymper.
• Den tidsstämpelbaserade algoritmen använder en tidsstämpel för att serialisera exekveringen av samtidiga transaktioner. Protokollet använder Systemtid eller logiskt räknas som en tidsstämpel.