Kan nogen forklare mig, om vi bruger foråret til transaktionsstyringen, hvordan samtidige opdateringer vil blive håndteret af dvale (i hukommelsen automatisk versionsstyring af dvale), eller jeg skal lægge versionskolonnen i databasen for at tage hånd om samtidige opdateringer manuelt.
Om du bruger Spring til transaktionsstyring eller ej, er ligegyldigt og er ikke relevant, når det kommer til samtidighedsstyring, dette håndteres faktisk af Hibernate. Hibernate kan bruge 2 strategier til at håndtere samtidige opdateringer:optimistisk låsning og pessimistisk låsning.
Optimistisk
Når du bruger optimistisk låsning, kortlægger du en speciel attribut (et tal, et tidsstempel) som en version (så du har faktisk en kolonne til det). Denne version læses, når du henter en enhed og inkluderes i where-klausulen under en opdatering og inkrementeret af Hibernate.
For at illustrere, hvordan dette virker, lad os forestille os, at du indlæser en person-entitet med id=1 og med en aktuel version=1. Efter en lagring udfører Hibernate noget som dette:
update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;
Så forestil dig nu, at du har to samtidige transaktioner kørende, hver af dem indlæser den samme enhed (samme versionsnummer) og ændring af navnet.
Lad os sige, at transaktion #1 er begået først, følgende forespørgsel udføres:
update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;
Det lykkes, og versionen bliver øget.
Så er transaktion #2 begået, følgende forespørgsel udføres:
update PERSON set ID=1, NAME='NAME 2', VERSION=2 where ID=1 and VERSION=1;
Denne vil ikke opdatere noget, fordi where-klausulen ikke matcher nogen post. Det er her, du får en optimistisk samtidighedsundtagelse.
Denne strategi er passende, når du ikke opretholder forbindelsen, når samtidige adgange ikke er hyppige, og skalerer rigtig godt. Og alt håndteres naturligvis gennemsigtigt af Hibernate for dig, så længe du kortlægger en versionsattribut.
Pessimistisk
Når du bruger pessimistisk låsning, låser Hibernate en registrering til din eksklusive brug, indtil du er færdig med den (typisk ved at bruge en SELECT ... FOR UPDATE ). Enhver anden samtidig transaktion, der forsøger at få adgang til den samme post, vil blive suspenderet, indtil låsen fjernes. Denne strategi giver bedre forudsigelighed til prisen af ydeevne og skalerer ikke i det uendelige.
Referencer
- Hibernate Core Reference Guide
- 11.3. Optimistisk samtidighedskontrol
- 11.4. Pessimistisk låsning