Aktivere transaksjonslåser i vårdata JPA

1. Oversikt

I denne raske opplæringen vil vi diskutere aktivering av transaksjonslåser i Spring Data JPA for tilpassede spørringsmetoder og forhåndsdefinerte lagrings-CRUD-metoder.

Vi vil også se på forskjellige låsetyper og sette tidsavbrudd for transaksjonslås.

2. Låsetyper

JPA har to hovedlåsetyper definert, som er pessimistisk låsing og optimistisk låsing.

2.1 Pessimistisk låsing

Når vi bruker pessimistisk låsing i en transaksjon og får tilgang til en enhet, vil den bli låst umiddelbart. Transaksjonen frigjør låsen enten ved å begå eller rulle tilbake transaksjonen.

2.2 Optimistisk låsing

I Optimistic Locking låser ikke transaksjonen enheten umiddelbart. I stedet lagrer transaksjonen vanligvis enhetens tilstand med et versjonsnummer tildelt.

Når vi prøver å oppdatere enhetens tilstand i en annen transaksjon, sammenligner transaksjonen det lagrede versjonsnummeret med det eksisterende versjonsnummeret under en oppdatering.

På dette punktet, hvis versjonsnummeret er forskjellig, betyr det at enheten ikke kan endres. Hvis det er en aktiv transaksjon, vil den transaksjonen bli rullet tilbake og den underliggende JPA-implementeringen vil kaste en OptimisticLockException.

Bortsett fra versjonsnummertilnærmingen, kan vi bruke andre tilnærminger som tidsstempler, beregning av hashverdi eller seriell kontrollsum, avhengig av hvilken tilnærming som er best egnet for vår nåværende utviklingskontekst.

3. Aktivere transaksjonslåser på spørringsmetoder

For å skaffe en lås på en enhet, kan vi kommentere målspørringsmetoden med en Låse merknader ved å passere den nødvendige typen låsemodus.

Låsemodustyper er enumverdier som skal spesifiseres mens du låser en enhet. Den spesifiserte låsemodusen overføres deretter til databasen for å bruke den tilsvarende låsen på enhetsobjektet.

For å spesifisere en lås på en tilpasset spørringsmetode i et Spring Data JPA-arkiv, kan vi kommentere metoden med @Låse og spesifiser ønsket låsemodus type:

@Lock (LockModeType.OPTIMISTIC_FORCE_INCREMENT) @Query ("SELECT c FROM Customer c WHERE c.orgId =? 1") public List fetchCustomersByOrgId (Long orgId);

For å håndheve låsen på forhåndsdefinerte depotmetoder som finn alle eller findById (id), må vi erklære metoden i depotet og kommentere metoden med Låse kommentar:

@Lock (LockModeType.PESSIMISTIC_READ) offentlig Valgfri findById (Long customerId);

Når låsen er eksplisitt aktivert og det ikke er noen aktiv transaksjon, vil den underliggende JPA-implementeringen kaste et TransactionRequiredException.

I tilfelle låsen ikke kan innvilges og låsekonflikten ikke resulterer i en tilbakeføring av transaksjonen, kaster JPA en LockTimeoutException. Men det markerer ikke den aktive transaksjonen for tilbakeføring.

4. Angi tidsavbrudd for transaksjonslås

Når du bruker pessimistisk låsing, vil databasen prøve å låse enheten umiddelbart. Den underliggende JPA-implementeringen kaster en LockTimeoutException når låsen ikke kan oppnås umiddelbart. For å unngå slike unntak kan vi spesifisere tidsavbruddsverdien for låsen.

I Spring Data JPA kan tidsavbrudd for låsing spesifiseres ved hjelp av QueryHints kommentar ved å plassere en QueryHint på søkemetoder:

@Lock (LockModeType.PESSIMISTIC_READ) @QueryHints ({@ QueryHint (name = "javax.persistence.lock.timeout", value = "3000")}) offentlig Valgfri findById (Long customerId);

Ytterligere detaljer om innstilling av hint for låsetid på forskjellige omfang finner du i denne ObjectDB-artikkelen.

5. Konklusjon

I denne opplæringen har vi lært de forskjellige typene transaksjonslåsmodus. Vi har lært hvordan du aktiverer transaksjonslåser i Spring Data JPA. Vi har også dekket innstilling av tidsavbrudd for lås.

Å bruke de riktige transaksjonslåsene på de rette stedene kan bidra til å opprettholde dataintegriteten i applikasjoner med høyt volum samtidig.

Når transaksjonen må overholde ACID-regler strengt, bør vi bruke pessimistisk låsing. Optimistisk låsing bør brukes når vi trenger å tillate flere samtidige avlesninger og når eventuell konsistens er akseptabel i applikasjonssammenheng.

Selvfølgelig kan eksempelkoden for både pessimistisk låsing og optimistisk låsing finnes på Github.


$config[zx-auto] not found$config[zx-overlay] not found