Ik begrijp de verschillen tussen optimistische en pessimistische vergrendeling. Kan iemand me nu uitleggen wanneer ik een van beide in het algemeen zou gebruiken?
En verandert het antwoord op deze vraag afhankelijk van het feit of ik een opgeslagen procedure gebruik om de zoekopdracht uit te voeren?
Maar om het even te checken, optimistisch betekent “vergrendel de tafel niet tijdens het lezen” en pessimistisch betekent “vergrendel de tafel tijdens het lezen”.
Antwoord 1, autoriteit 100%
Optimistic Lockingis een strategie waarbij u een record leest, een versienummer noteert ( andere methoden om dit te doen, zijn datums, tijdstempels of checksums/hashes) en controleer of de versie niet is gewijzigd voordat u het record terugschrijft. Wanneer u de record terugschrijft, filtert u de update op de versie om er zeker van te zijn dat deze atomair is. (d.w.z. niet is bijgewerkt tussen het moment dat u de versie controleert en het record naar de schijf schrijft) en de versie in één keer bijwerkt.
Als het record vuil is (d.w.z. een andere versie dan de uwe), annuleert u de transactie en kan de gebruiker deze opnieuw starten.
Deze strategie is het meest van toepassing op systemen met een hoog volume en drielaagse architecturen waarbij u niet noodzakelijkerwijs een verbinding met de database onderhoudt voor uw sessie. In deze situatie kan de client de databasevergrendelingen niet daadwerkelijk handhaven, omdat de verbindingen uit een pool worden gehaald en u mogelijk niet dezelfde verbinding van de ene toegang naar de andere gebruikt.
Pessimistische vergrendelingis wanneer u het record vergrendelt voor exclusief gebruik totdat u ermee klaar. Het heeft een veel betere integriteit dan optimistische vergrendeling, maar vereist dat u voorzichtig bent met uw toepassingsontwerp om deadlockste vermijden . Om pessimistische vergrendeling te gebruiken, hebt u ofwel een directe verbinding met de database nodig (zoals gewoonlijk het geval is in een twee tier client serverapplicatie) of een extern beschikbare transactie-ID die onafhankelijk van de verbinding kan worden gebruikt.
In het laatste geval opent u de transactie met de TxID en maakt u vervolgens opnieuw verbinding met die ID. Het DBMS onderhoudt de vergrendelingen en stelt u in staat om de sessie weer op te halen via de TxID. Dit is hoe gedistribueerde transacties met behulp van tweefasige commit-protocollen (zoals XAof COM+ Transacties) werken.
Antwoord 2, autoriteit 22%
Optimistische vergrendeling wordt gebruikt wanneer u niet veel botsingen verwacht. Het kost minder om een normale operatie uit te voeren, maar als de botsing WEL optreedt, betaalt u een hogere prijs om deze op te lossen als de transactie wordt afgebroken.
Pessimistische vergrendeling wordt gebruikt wanneer een botsing wordt verwacht. De transacties die de synchronisatie zouden schenden, worden eenvoudigweg geblokkeerd.
Om het juiste vergrendelingsmechanisme te selecteren, moet u het aantal lees- en schrijfbewerkingen inschatten en dienovereenkomstig plannen.
Antwoord 3, autoriteit 15%
Als je met conflicten omgaat, heb je twee opties:
- Je kunt proberen het conflict te vermijden, en dat is wat Pessimistic Locking doet.
- of, je zou het conflict kunnen laten optreden, maar je moet het detecteren bij het plegen van je transacties, en dat is wat optimistische vergrendeling doet.
Laten we nu rekening houden met de volgende verloren update-anomalie:
De verloren update-anomalie kan gebeuren in het gelezen gepleegde isolatieniveau.
In het bovenstaande diagram kunnen we zien dat Alice gelooft dat ze 40 van haar accountkan opnemen, maar beseft dat Bob het saldo van de account niet heeft gewijzigd, en nu zijn er slechts 20 in dit account. .
Pessimistische vergrendeling
Pessimistische vergrendeling behaalt dit doel door een gedeeld of leesvergrendeling op het account te nemen, zodat Bob wordt voorkomen dat Bob het account wordt gewijzigd.
In het bovenstaande diagram krijgen zowel Alice als Bob een leesvergrendeling op de accounttabelrij die beide gebruikers hebben gelezen. De database verwerft deze vergrendelingen op SQL Server bij het gebruikbaar lezen of serialiseerbaar.
Omdat zowel Alice als Bob de accounthebben gelezen met de PK-waarde van 1, kunnen geen van beiden het veranderen totdat een gebruiker het leesvergrendeling vrijgeeft. Dit komt omdat een schrijfbewerking een write / exclusieve vergrendelingsverwerving vereist en gedeelde / leesvergrendelingen voorkomt, schrijf / exclusieve sloten.
Nadat Alice haar transactie heeft gecommitteerd en het leesvergrendeling werd uitgebracht op de accountRow, Bob UPDATEzal de wijziging hervatten en toepassen. Totdat Alice de leesvergrendeling vrijgeeft, Bob’s update-blokken.
Optimistische vergrendeling
Optimistische vergrendeling stelt het conflict mogelijk, maar detecteert deze bij het toepassen van de update van Alice als de versie is gewijzigd.
Deze keer hebben we een extra versionkolom. De kolom versionwordt telkens verhoogd telkens wanneer een update of verwijdering wordt uitgevoerd, en wordt ook gebruikt in de waarnemingsclausule van de update- en verwijderingsverklaringen. Voor dit aan het werk moeten we de SELECTEERD geven en de huidige versionlezen voordat u de update of verwijdering wilt uitvoeren, omdat we niet weten welke versiewaarde naar de where-clausule of om te passeren .
Toepassingsniveau Transacties
Relationele databasesystemen zijn in de vroege jaren ’90 van de jaren 70 naar voren gebracht wanneer een klant typisch, verbinding maakt met een mainframe via een terminal. Daarom hebben we nog steeds databasesystemen voorwaarden zoals session-instelling definiëren.
Tegenwoordig worden via internet niet langer gelezen en schrijft in de context van dezelfde database-transactie en is zuur niet langer voldoende.
Bekijk bijvoorbeeld het volgende gebruik Case:
Zonder optimistische vergrendeling is er geen manier waarop deze verloren update is gepakt, zelfs als de database-transacties serialiseerbaar gebruikten. Dit komt omdat lees en schrijft worden uitgevoerd in afzonderlijke HTTP-aanvragen, vandaar op verschillende databasetransacties.
Dus, optimistische vergrendeling kan u helpen om verloren updates te voorkomen, zelfs bij het gebruik van transacties op toepassingsniveau die ook de door de gebruiker-denktijd opnemen.
Conclusie
Optimistische vergrendeling is een zeer nuttige techniek en werkt prima, zelfs bij gebruik van minder strikte isolatieniveaus, zoals Read Committed, of wanneer lees- en schrijfbewerkingen worden uitgevoerd in daaropvolgende databasetransacties.
Het nadeel van optimistische vergrendeling is dat een rollback wordt geactiveerd door het gegevenstoegangsframework bij het vangen van een OptimisticLockException, waardoor al het werk verloren gaat dat we eerder hebben gedaan door de momenteel uitgevoerde transactie.
p>
Hoe meer twist, hoe meer conflicten en hoe groter de kans op het afbreken van transacties. Terugdraaien kan kostbaar zijn voor het databasesysteem omdat het alle huidige hangende wijzigingen moet terugdraaien, waarbij zowel tabelrijen als indexrecords betrokken kunnen zijn.
Om deze reden is pessimistische vergrendeling wellicht meer geschikt wanneer conflicten vaak voorkomen, omdat het de kans op het terugdraaien van transacties verkleint.
Antwoord 4, autoriteit 9%
Optimistisch gaat ervan uit dat er niets gaat veranderen terwijl je het leest.
Pessimistisch gaat ervan uit dat iets zal gebeuren en vergrendelt het dus.
Als het niet essentieel is dat de gegevens perfect worden gelezen, gebruik dan optimistisch. Het kan zijn dat u af en toe ‘vies’ wordt gelezen, maar het is veel minder waarschijnlijk dat dit leidt tot impasses en dergelijke.
De meeste webapplicaties zijn in orde met vuile leesacties – in het zeldzame geval dat de gegevens niet precies kloppen bij de volgende herlaadbeurt.
Gebruik pessimistisch voor exacte gegevensbewerkingen (zoals bij veel financiële transacties). Het is essentieel dat de gegevens nauwkeurig worden gelezen, zonder niet-weergegeven wijzigingen – de extra vergrendelingsoverhead is het waard.
O, en Microsoft SQL-server is standaard ingesteld op paginavergrendeling – in feite de rij die u aan het lezen bent en een paar aan weerszijden. Rijvergrendeling is nauwkeuriger, maar veel langzamer. Het is vaak de moeite waard om uw transacties in te stellen op read-committed of no-lock om impasses tijdens het lezen te voorkomen.
Antwoord 5, autoriteit 3%
Ik zou nog een geval bedenken waarin pessimistische vergrendeling een betere keuze zou zijn.
Voor optimistische vergrendeling moet elke deelnemer aan gegevenswijziging akkoord gaan met het gebruik van dit soort vergrendeling. Maar als iemand de gegevens wijzigt zonder rekening te houden met de versiekolom, zal dit het hele idee van de optimistische vergrendeling bederven.
Antwoord 6, autoriteit 2%
Er zijn in principe twee meest populaire antwoorden. De eerstezegt eigenlijk
Optimistic heeft een architectuur met drie niveaus nodig waarbij u niet noodzakelijkerwijs een verbinding met de database onderhoudt voor uw sessie, terwijl Pessimistic Locking is wanneer u het record vergrendelt voor exclusief gebruik totdat u ermee klaar bent. Het heeft een veel betere integriteit dan optimistische vergrendeling, je hebt ofwel een directe verbinding met de database nodig.
optimistisch (versiebeheer) is sneller omdat er geen vergrendeling is, maar (pessimistische) vergrendeling presteert beter wanneer de strijd hoog is en het is beter om het werk te voorkomen in plaats van het weg te gooien en opnieuw te beginnen.
of
Optimistische vergrendeling werkt het beste bij zeldzame botsingen
Zoals het staatop deze pagina.
Ik heb mijn antwoord gemaakt om uit te leggen hoe “verbinding behouden” gerelateerd is aan “lage botsingen”.
Om te begrijpen welke strategie het beste voor u is, denk dan niet over de transacties per seconde die uw DB heeft, maar de duur van een enkele transactie. Normaal gesproken opent u Trasnaction, Performa Operation en sluit de transactie. Dit is een korte, klassieke transactie ANSI in gedachten en prima om weg te komen met vergrendeling. Maar hoe voert u een ticketreserveringssysteem uit waar veel klanten dezelfde kamers / zitplaatsen tegelijkertijd reserveren?
U bladert door de aanbiedingen, vul het formulier in met veel beschikbare opties en huidige prijzen. Het kost veel tijd en opties kunnen verouderd raken, alle prijzen ongeldig tussen u begonnen met het invullen van het formulier en drukt u op de knop “I akkoord” omdat er geen vergrendeling was op de gegevens die u hebt geopend en iemand anders, meer wendbaar Al de prijzen wijzigen en u moet opnieuw opstarten met nieuwe prijzen.
U kunt alle opties vergrendelen terwijl u ze leest, in plaats daarvan. Dit is pessimistisch scenario. Je ziet waarom het zuigt. Uw systeem kan worden neergehaald door een enkele clown die eenvoudigweg een reservering start en rookt. Niemand kan alles reserveren voordat hij klaar is. Uw cashflow daalt naar nul. Dat is de reden waarom, optimistische reserveringen worden gebruikt in werkelijkheid. Degenen die te lang dauwen, moeten hun reservering tegen hogere prijzen opnieuw starten.
In deze optimistische benadering moet je alle gegevens die je leest vastleggen (zoals in mijn Herhaald lezen) en komen naar het commit-punt met uw versie van gegevens (ik wil aandelen kopen tegen de prijs die u in deze offerte hebt weergegeven, niet de huidige prijs). Op dit punt wordt een ANSI-transactie gemaakt, die de DB vergrendelt, controleert of er niets is gewijzigd en uw bewerking begaat/afbreekt. IMO, dit is een effectieve emulatie van MVCC, die ook wordt geassocieerd met Optimistic CC en er ook van uitgaat dat uw transactie herstart in geval van afbreken, dat wil zeggen dat u een nieuwe reservering maakt. Een transactie hier omvat beslissingen van een menselijke gebruiker.
Ik begrijp nog lang niet hoe ik de MVCC handmatig moet implementeren, maar ik denk dat langlopende transacties met een herstartoptie de sleutel zijn om het onderwerp te begrijpen. Corrigeer me als ik ergens fout zit. Mijn antwoord werd gemotiveerd door deze Alex Kuznecov hoofdstuk.
Antwoord 7
In de meeste gevallen is optimistische vergrendeling efficiënter en biedt het betere prestaties. Houd bij het kiezen tussen pessimistische en optimistische vergrendeling rekening met het volgende:
-
Pessimistische vergrendeling is handig als er veel updates zijn en
relatief grote kans dat gebruikers tegelijkertijd gegevens proberen bij te werken
tijd. Als elke bewerking bijvoorbeeld een groot aantal
records per keer (de bank kan rente-inkomsten toevoegen aan elke
account aan het einde van elke maand), en er zijn twee applicaties actief
dergelijke operaties tegelijkertijd zullen leiden tot conflicten. -
Pessimistische vergrendeling is ook geschikter in toepassingen die kleine tabellen bevatten die regelmatig worden bijgewerkt. In het geval van deze zogenaamde hotspots zijn conflicten zo waarschijnlijk dat optimistische vergrendeling moeite kost om conflicterende transacties terug te draaien.
-
Optimistische vergrendeling is handig als de kans op conflicten erg is
laag – er zijn veel records maar relatief weinig gebruikers, of heel weinig updates en meestal leesbewerkingen.
Antwoord 8
Er zijn hierboven veel goede dingen gezegd over optimistische en pessimistische vergrendeling.
Een belangrijk punt om te overwegen is het volgende:
Als we optimistische vergrendeling gebruiken, moeten we op onze hoede zijn voor het feit dat de toepassing zich van deze fouten zal herstellen.
Vooral in asynchrone berichtgestuurde architecturen kan dit leiden tot niet-bestaande berichtverwerking of verloren updates.
Er moet over scenario’s voor storingen worden nagedacht.
Antwoord 9
Een use case voor optimistische locking is om uw applicatie de database te laten gebruiken zodat een van uw threads/hosts een taak kan ‘claimen’. Dit is een techniek die mij regelmatig van pas komt.
Het beste voorbeeld dat ik kan bedenken is een taakwachtrij die is geïmplementeerd met behulp van een database, met meerdere threads die tegelijkertijd taken claimen. Als een taak de status ‘Beschikbaar’, ‘Geclaimd’, ‘Voltooid’ heeft, kan een db-query iets zeggen als ‘Set status=’Claimed’ where status=’Available’. Als meerdere threads de status op deze manier proberen te wijzigen, alles behalve de eerste thread zal mislukken vanwege vuile gegevens.
Merk op dat dit een use-case is waarbij alleen optimistische vergrendeling betrokken is. Dus als alternatief voor de opmerking “Optimistische vergrendeling wordt gebruikt als u niet veel botsingen verwacht”, kan het ook worden gebruikt waar u botsingen verwacht maar precies één transactie wilt laten slagen.