Transaktioner med Spring og JPA

1. Oversigt

Denne tutorial vil diskutere den rigtige måde at konfigurere forårstransaktioner på, hvordan man bruger @Transaktionel kommentar og almindelige faldgruber.

For en mere dybtgående diskussion om kernepræstenskonfigurationen, tjek Spring with JPA tutorial.

Dybest set er der to forskellige måder at konfigurere Transaktioner - kommentarer og AOP - hver med deres egne fordele. Vi diskuterer den mere almindelige kommentar-konfiguration her.

2. Konfigurer transaktioner

Forår 3.1 introducerer det @EnableTransactionManagement kommentar som vi kan bruge i en @Konfiguration klasse og aktivere transaktionsstøtte:

@Configuration @EnableTransactionManagement offentlig klasse PersistenceJPAConfig {@Bean public LocalContainerEntityManagerFactoryBean entityManagerFactoryBean () {// ...} @Bean public PlatformTransactionManager transactionManager () {JpaTransactionManager transactionManager = ny JpaTransactionManager transactionManager.setEntityManagerFactory (entityManagerFactoryBean (). getObject ()); returtransaktionManager; }}

Imidlertid, hvis vi bruger et Spring Boot-projekt og har en spring-data- * eller spring-tx-afhængighed på klassestien, så er transaktionsstyring aktiveret som standard.

3. Konfigurer transaktioner med XML

Før 3.1, eller hvis Java ikke er en mulighed, er her XML-konfigurationen, der bruger annoteringsdrevet og navneområdet understøtter:

4. Den @Transaktionel Kommentar

Med konfigurerede transaktioner kan vi nu kommentere en bønne med @Transaktionel enten på klasse- eller metodeniveau:

@Service @Transactional public class FooService {// ...}

Annotationen understøtter yderligere konfiguration såvel:

  • det Formeringstype af transaktionen
  • det Isolationsniveau af transaktionen
  • -en Tiden er gået til operationen indpakket i transaktionen
  • -en readOnly flag - et tip til den udholdenhedsudbyder, at transaktionen kun skal læses
  • det Tilbageførsel regler for transaktionen

Bemærk, at - som standard sker tilbageførsel kun til runtime, kun ikke-markerede undtagelser. Den markerede undtagelse udløser ikke en tilbageførsel af transaktionen. Vi kan selvfølgelig konfigurere denne adfærd med tilbageførsel til og noRollbackFor annoteringsparametre.

5. Potentielle faldgruber

5.1. Transaktioner og fuldmægtige

På et højt niveau Spring opretter fuldmagter for alle de klasser, der er kommenteret med @Transaktionel - enten på klassen eller på en af ​​metoderne. Proxyen tillader rammen at indsprøjte transaktionslogik før og efter kørselsmetoden - hovedsageligt til start og begivenhed af transaktionen.

Hvad der er vigtigt at huske på er, at hvis transaktionsbønnen implementerer en grænseflade, vil proxy'en som standard være en Java Dynamic Proxy. Dette betyder, at kun eksterne metodeopkald, der kommer ind gennem proxyen, bliver opfanget. Ethvert selvopkaldsopkald starter ikke nogen transaktion, selvom metoden har @Transaktionel kommentar.

En anden advarsel ved at bruge fuldmagter er det kun offentlige metoder skal kommenteres @Transaktionel. Metoder til enhver anden synlighed ignorerer simpelthen kommentaren lydløst, da disse ikke er proxy.

Denne artikel diskuterer yderligere proxying faldgruber i detaljer her.

5.2. Ændring af isolationsniveauet

Vi kan også ændre transaktionsisolationsniveauet:

@Transactional (isolation = Isolation.SERIALIZABLE)

Bemærk, at dette faktisk er blevet introduceret i foråret 4.1; hvis vi kører ovenstående eksempel før forår 4.1, vil det resultere i:

org.springframework.transaction.InvalidIsolationLevelException: Standard JPA understøtter ikke brugerdefinerede isolationsniveauer - brug en special JpaDialect til din JPA-implementering

5.3. Skrivebeskyttede transaktioner

Det Læs kun flag genererer normalt forvirring, især når man arbejder med JPA; fra Javadoc:

Dette tjener bare som et tip til det faktiske transaktionsundersystem; det vil ikke nødvendigvis forårsage fejl i skriveadgangsforsøg. En transaktionsadministrator, der ikke kan fortolke det skrivebeskyttede tip, vil ikke smid en undtagelse, når du bliver bedt om en skrivebeskyttet transaktion.

Faktum er, at Vi kan ikke være sikre på, at en indsættelse eller opdatering ikke finder sted, når Læs kun flag er sat. Denne adfærd er leverandørafhængig, mens JPA er leverandøragnostiker.

Det er også vigtigt at forstå det det Læs kun flag er kun relevant i en transaktion. Hvis en handling finder sted uden for en transaktionskontekst, ignoreres flag simpelthen. Et simpelt eksempel på det vil kalde en metode, der er kommenteret med:

@Transactional (propagation = Propagation.SUPPORTS, readOnly = true)

fra en ikke-transaktionel kontekst - en transaktion oprettes ikke og Læs kun flag ignoreres.

5.4. Transaktionslogning

En nyttig metode til at forstå transaktionsrelaterede problemer er finjustering af logning i transaktionspakkerne. Den relevante pakke i foråret er “org.springframework.transaction ”, som skal konfigureres med et logningsniveau af TRACE.

6. Konklusion

Vi dækkede den grundlæggende konfiguration af transaktionssemantik ved hjælp af både Java og XML, hvordan man bruger @Transaktionel og bedste praksis i en transaktionsstrategi.

Som altid er koden præsenteret i denne artikel tilgængelig på Github.


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