Aktivering af transaktionslåse i Spring Data JPA

1. Oversigt

I denne hurtige vejledning diskuterer vi aktivering af transaktionslåse i Spring Data JPA til brugerdefinerede forespørgselsmetoder og foruddefinerede lagrings-CRUD-metoder.

Vi vil også se på forskellige låsetyper og indstille timeouts for transaktionslås.

2. Låsetyper

JPA har to hovedlåsetyper defineret, som er pessimistisk låsning og optimistisk låsning.

2.1 Pessimistisk låsning

Når vi bruger pessimistisk låsning i en transaktion og får adgang til en enhed, låses den med det samme. Transaktionen frigiver låsen enten ved at begå eller rulle tilbage transaktionen.

2.2 Optimistisk låsning

I optimistisk låsning låser transaktionen ikke enheden med det samme. I stedet gemmer transaktionen normalt enhedens tilstand med et versionsnummer tildelt.

Når vi prøver at opdatere enhedens tilstand i en anden transaktion, sammenligner transaktionen det gemte versionsnummer med det eksisterende versionsnummer under en opdatering.

På dette tidspunkt, hvis versionsnummeret adskiller sig, betyder det, at enheden ikke kan ændres. Hvis der er en aktiv transaktion, rulles denne transaktion tilbage, og den underliggende JPA-implementering kaster en OptimisticLockException.

Bortset fra versionsnummermetoden kan vi bruge andre tilgange såsom tidsstempler, beregning af hashværdi eller seriel kontrolsum, afhængigt af hvilken tilgang der er bedst egnet til vores nuværende udviklingskontekst.

3. Aktivering af transaktionslåse på forespørgselsmetoder

For at erhverve en lås på en enhed kan vi kommentere målforespørgselsmetoden med en Låse annotering ved at passere den krævede type låsefunktion.

Låsetilstandstyper er enumværdier, der skal specificeres, mens en enhed låses. Den specificerede låsemodus overføres derefter til databasen for at anvende den tilsvarende lås på enhedsobjektet.

For at specificere en lås på en tilpasset forespørgselsmetode i et Spring Data JPA-arkiv kan vi kommentere metoden med @Låse og angiv den krævede låsemodus type:

@Lock (LockModeType.OPTIMISTIC_FORCE_INCREMENT) @Query ("VÆLG c FRA Kunde c HVOR c.orgId =? 1") offentlig liste fetchCustomersByOrgId (Long orgId);

At håndhæve låsen på foruddefinerede arkivmetoder som f.eks findAlle eller findById (id), vi er nødt til at erklære metoden i arkivet og kommentere metoden med Låse kommentar:

@Lock (LockModeType.PESSIMISTIC_READ) offentlig Valgfri findById (lang kunde-id);

Når låsen er eksplicit aktiveret, og der ikke er nogen aktiv transaktion, kaster den underliggende JPA-implementering et TransactionRequiredException.

Hvis låsen ikke kan tildeles, og låsekonflikten ikke resulterer i en tilbageførsel af transaktion, kaster JPA en LockTimeoutException. Men det markerer ikke den aktive transaktion for tilbageførsel.

4. Indstilling af timeouts for transaktionslås

Når du bruger pessimistisk låsning, forsøger databasen med det samme at låse enheden. Den underliggende JPA-implementering kaster en LockTimeoutException når låsen ikke kan opnås med det samme. For at undgå sådanne undtagelser kan vi angive værdien for låsetimeout.

I Spring Data JPA kan låsetimeout specificeres ved hjælp af QueryHints kommentar ved at placere en QueryHint om forespørgselsmetoder:

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

Yderligere detaljer om indstilling af tip til lås-timeout til forskellige rækkevidde kan findes i denne ObjectDB-artikel.

5. Konklusion

I denne vejledning har vi lært de forskellige typer transaktionslåsetilstande. Vi har lært, hvordan du aktiverer transaktionslåse i Spring Data JPA. Vi har også dækket indstilling af låsetimeout.

Anvendelse af de rigtige transaktionslåse på de rigtige steder kan hjælpe med at opretholde dataintegriteten i applikationer til samtidig brug af store mængder.

Når transaktionen skal overholdes strengt med ACID-regler, skal vi bruge pessimistisk låsning. Optimistisk låsning skal anvendes, når vi har brug for at tillade flere samtidige læsninger, og når en eventuel konsistens er acceptabel inden for applikationens sammenhæng.

Selvfølgelig kan prøvekoden til både pessimistisk låsning og optimistisk låsning findes på Github.


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