Vad är samtidighetskontroll?
Samtidighetskontroll i databashanteringssystem är ett förfarande för att hantera samtidiga operationer utan att strida mot varandra. Det säkerställer att databastransaktioner utförs samtidigt och exakt för att producera korrekta resultat utan att kränka dataintegriteten för respektive databas.
Samtidig åtkomst är ganska lätt om alla användare bara läser data. Det finns inget sätt de kan störa varandra. Även om det för någon praktisk databas skulle det 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 ta itu med sådana konflikter, som oftast förekommer med ett fleranvändarsystem. Därför är samtidighetskontroll det viktigaste elementet för att ett databashanteringssystem ska fungera korrekt där två eller flera databastransaktioner utförs samtidigt, vilket kräver åtkomst till samma data.
I den här handledningen lär du dig
- Vad är samtidighetskontroll?
- Potentiella problem med samtidighet
- Varför använda Concurrency-metoden?
- Protokoll för samtidighetskontroll
- Låsbaserade protokoll
- Tvåfaslåsningsprotokoll (2PL)
- Tidsstämpelbaserade protokoll
- Valideringsbaserat protokoll
- Kännetecken för Good Concurrency Protocol
Potentiella problem med samtidighet
Här är några problem som du sannolikt kommer att möta när du använder metoden DBMS Concurrency Control:
- Förlorade uppdateringar inträffar när flera transaktioner väljer samma rad och uppdaterar raden baserat på det valda värdet
- Oförpliktade beroendeproblem uppstår när den andra transaktionen väljer en rad som uppdateras av en annan transaktion ( smutsig läsning )
- Icke-repeterbar 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 en sammanfattning över värdet av alla förekomster av ett upprepat dataobjekt, och andra transaktion uppdaterar 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 Concurrency control method är DBMS:
- Att tillämpa isolering genom ömsesidig uteslutning mellan motstridiga transaktioner
- För att lösa problem med läs-skriv och skriv-skriv-konflikt
- För att bevara databaskonsistens genom att ständigt bevara körningshinder
- Systemet måste kontrollera interaktionen mellan samtidiga transaktioner. Denna kontroll uppnås med hjälp av system för samtidig kontroll.
- Samtidighetskontroll hjälper till att säkerställa serieiserbarhet
Exempel
Antag att två personer som går till elektroniska kiosker samtidigt för att köpa en filmbiljett för samma film och samma visningstid.
Det finns emellertid bara en plats kvar till filmen i just den teatern. Utan samtidighetskontroll i DBMS är det möjligt att båda filmbesökarna kommer att köpa en biljett. Samtidig kontrollmetod tillåter dock inte att detta händer. Båda filmbesökarna kan fortfarande få tillgång till information skriven i databasen för filmplatser. Men samtidig valutakontroll 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 som de tillåter och mängden allmänna omkostnader som de inför. Följande är Concurrency Control-tekniker i DBMS:
- Låsbaserade protokoll
- Tvåfaslåsprotokoll
- Tidsstämpelbaserade protokoll
- Valideringsbaserade protokoll
Låsbaserade protokoll
Låsbaserade protokoll i DBMS är en mekanism där en transaktion inte kan läsa eller skriva data förrän den får ett lämpligt lås. Låsbaserade protokoll hjälper till att eliminera det samtidiga problemet i DBMS för samtidiga transaktioner genom att låsa eller isolera en viss transaktion för en enskild användare.
Ett lås är en datavariabel som är associerad med ett dataobjekt. Detta lås betyder att operationer som kan utföras på dataposten. Lås i DBMS hjälper till att synkronisera åtkomst till databasobjekten genom samtidiga transaktioner.
Alla låsförfrågningar görs till concurrency-control manager. Transaktioner fortsätter bara 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 upplåst.
Delad / exklusiv: Denna typ av låsmekanism skiljer åt lås i DBMS baserat på deras användning. 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 också ett skrivskyddat lås. Med det delade låset kan dataobjektet delas mellan transaktionerna. Detta beror på att du aldrig har behörighet att uppdatera data om dataposten.
Tänk till exempel på ett fall där två transaktioner läser en persons kontosaldo. Databasen låter dem läsa genom att placera ett delat lås. Men om en annan transaktion vill uppdatera kontosaldot förhindrar delat lås det tills läsningsprocessen är över.
2. Exklusivt lås (X):
Med Exclusive Lock kan ett dataobjekt läsas och skrivas. Detta är exklusivt och kan inte hållas samtidigt på samma datapost. X-lock begärs med hjälp av lock-x-instruktion. Transaktioner kan låsa upp dataposten efter avslutad "skriv" -åtgärd.
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 exklusivt lås denna operation.
3. Förenklat låsprotokoll
Denna typ av låsbaserade protokoll gör det möjligt för transaktioner att få ett lås på varje objekt innan operationen påbörjas. Transaktioner kan låsa upp dataposten efter avslutad "skriv" -operation.
4. Förkrav om låsning
Pre-claiming lock protocol hjälper till att utvärdera operationer och skapa en lista med nödvändiga dataobjekt som behövs för att initiera en exekveringsprocess. I situationen när alla lås beviljas utförs transaktionen. Därefter släpps alla lås när all verksamhet är över.
Svält
Svält är situationen när en transaktion behöver 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 hanteras inte ordningen för låsta föremål ordentligt
- Vid resursläckage
- Samma transaktion väljs som ett offer upprepade gånger
Dödläge
Dödläge hänvisar till en specifik situation där två eller flera processer väntar på varandra för att frigöra en resurs eller mer än två processer väntar på resursen i en cirkulär kedja.
Tvåfaslåsprotokoll
Tvåfaslåsprotokoll, även känt som 2PL-protokoll, är en metod för samtidig valutakontroll i DBMS som säkerställer serieiserbarhet genom att tillämpa ett lås på transaktionsdata som blockerar andra transaktioner för att få åtkomst till samma data samtidigt. Tvåfaslåsprotokoll hjälper till att eliminera samtidighetsproblemet i DBMS.
Detta låsprotokoll delar upp exekveringsfasen av en transaktion i tre olika delar.
- I den första fasen, när transaktionen börjar genomföras, krävs det tillstånd för de lås som 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 det bara de förvärvade låsarna.
Tvåfaslåsningsprotokollet gör det möjligt för varje transaktion att göra en låsning eller låsa upp begäran i två steg:
- Växande fas : I denna fas kan transaktioner få lås men kanske inte frigöra några lås.
- Krympningsfas : I denna fas kan en transaktion frigöra lås men inte få något nytt lås
Det är sant att 2PL-protokollet erbjuder serieiserbarhet. Det säkerställer dock inte att dödlås inte sker.
I ovanstående diagram kan du se att lokala och globala dödlägesdetektorer söker efter dödlås och löser dem genom att återuppta transaktioner till sina ursprungliga tillstånd.
Strikt tvåfaslåsningsmetod
Strict-Two-phase locking system liknar nästan 2PL. Den enda skillnaden är att Strict-2PL aldrig släpper ett lås efter att ha använt det. Det håller alla lås tills engagemangspunkten och släpper alla lås på en gång när processen är över.
Centraliserad 2PL
I Centralized 2 PL är en enda webbplats ansvarig för låshanteringsprocessen. Den har bara en låshanterare för hela DBMS.
Primärkopia 2PL
Primär kopia 2PL-mekanism, många låshanterare distribueras till olika webbplatser. Därefter ansvarar en viss låshanterare för att hantera låset för en uppsättning dataobjekt. När den primära kopian har uppdaterats överförs ändringen till slavarna.
Distribuerad 2PL
I denna typ av tvåfaslåsmekanism distribueras låshanterare till alla webbplatser. De ansvarar för att hantera lås för data på den webbplatsen. Om inga data replikeras motsvarar det primärkopia 2PL. Kommunikationskostnaderna för Distribuerad 2PL är ganska högre än primärkopia 2PL
Tidsstämpelbaserade protokoll
Tidsstämpelbaserat protokoll i DBMS är en algoritm som använder systemtiden eller den logiska räknaren som en tidsstämpel för att serieisera utförandet av samtidiga transaktioner. Det tidsstämpelbaserade protokollet säkerställer att alla motstridiga läs- och skrivoperationer utförs i en tidsstämpelordning.
Den äldre transaktionen prioriteras alltid i denna metod. Den använder systemtid för att bestämma tidstämpeln för transaktionen. Detta är det mest använda samtidighetsprotokollet.
Låsbaserade protokoll hjälper dig att hantera ordern mellan de motstridiga transaktionerna när de kommer att genomföras. Tidsstämpelbaserade protokoll hanterar konflikter så snart en operation skapas.
Exempel:
Suppose there are there transactions T1, T2, and T3.T1 has entered the system at time 0010T2 has entered the system at 0020T3 has entered the system at 0030Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.
Fördelar :
- Scheman kan serienummeras precis som 2PL-protokoll
- Ingen väntan på transaktionen, vilket eliminerar risken för blockeringar!
Nackdelar:
Svält är möjligt om samma transaktion startas om och kontinuerligt avbryts
Valideringsbaserat protokoll
Valideringsbaserat protokoll i DBMS, även känt som Optimistic Concurrency Control Technique, är en metod för att undvika samtidighet i transaktioner. I detta protokoll uppdateras de lokala kopiorna av transaktionsdata snarare än själva data, vilket resulterar i mindre störningar under transaktionen.
Valideringsbaserat protokoll utförs i följande tre faser:
- Läs fas
- Valideringsfas
- 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 på den faktiska databasen.
Valideringsfas
I valideringsfasen kontrolleras informationen för att säkerställa att det inte sker någon överträdelse av serieiserbarheten när transaktionsuppdateringarna tillämpas i databasen.
Skriv fas
I skrivfasen tillämpas uppdateringarna i databasen om valideringen lyckas, annars; uppdateringarna tillämpas inte och transaktionen rullas tillbaka.
Kännetecken 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 genomdriva vissa begränsningar för strukturen för atomåtgärder i transaktioner.
Sammanfattning
- Samtidighetskontroll är proceduren i DBMS för att hantera samtidiga operationer utan att strida mot varandra.
- Förlorade uppdateringar, smutsig läsning, icke-repeterbar läsning och felaktig sammanfattning är problem som ställs inför på grund av brist på samtidig valutakontroll.
- Låsbaserade, tvåfasiga, tidsstämpelbaserade, valideringsbaserade är typer av protokoll för hantering av samtidighet
- 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 skaffa ett lås efter att det släppt ett av dess lås. Den har två faser som växer och krymper.
- Den tidsstämpelbaserade algoritmen använder en tidsstämpel för att serieera utförandet av samtidiga transaktioner. Protokollet använder System Time eller Logical Count som en tidsstämpel.