streamalism.org

1. Oversikt

Denne opplæringen vil diskutere riktig måte å konfigurere vårtransaksjoner på, hvordan du bruker @Transaksjonell kommentar og vanlige fallgruver.

For en mer inngående diskusjon om kjernepresentasjonskonfigurasjonen, sjekk ut våren med JPA-opplæringen.

I utgangspunktet er det to forskjellige måter å konfigurere transaksjoner - merknader og AOP - hver med sine egne fordeler. Vi skal diskutere den mer vanlige kommentar-konfigurasjonen her.

2. Konfigurer transaksjoner

Våren 3.1 introduserer de @EnableTransactionManagement kommentar som vi kan bruke i en @Konfigurasjon klasse og aktivere transaksjonsstøtte:

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

Derimot, hvis vi bruker et Spring Boot-prosjekt, og har en vår-data- * eller vår-tx-avhengighet på klassestien, vil transaksjonsadministrasjon være aktivert som standard.

3. Konfigurer transaksjoner med XML

Før 3.1 eller hvis Java ikke er et alternativ, her er XML-konfigurasjonen som bruker annotasjonsdrevet og navneområdet støtte:

4. Den @Transaksjonell Kommentar

Med konfigurerte transaksjoner kan vi nå kommentere en bønne med @Transaksjonell enten på klasse- eller metodenivå:

@Service @Transaksjonell offentlig klasse FooService {// ...}

Kommentaren støtter ytterligere konfigurasjon også:

• de Forplantningstype av transaksjonen
• de Isolasjonsnivå av transaksjonen
• en Pause for operasjonen som er pakket inn av transaksjonen
• en lesBare flagg - et hint for utholdenhetsleverandøren om at transaksjonen skal være skrivebeskyttet
• de Tilbakeslag regler for transaksjonen

Merk at - som standard skjer tilbakeføring kun for kjøretid, unchecked unntak. Det avmerkede unntaket utløser ikke tilbakestilling av transaksjonen. Vi kan selvfølgelig konfigurere denne oppførselen med tilbakestilling For og noRollbackFor merknadsparametere.

5. Potensielle fallgruver

5.1. Transaksjoner og fullmakter

På høyt nivå, Våren oppretter fullmakter for alle klassene som er merket med @Transaksjonell - enten på klassen eller på noen av metodene. Fullmakten tillater rammeverket å injisere transaksjonslogikk før og etter kjøringsmetoden - hovedsakelig for å starte og begå transaksjonen.

Det som er viktig å huske på er at hvis transaksjonsbønnen implementerer et grensesnitt, vil proxyen som standard være en Java Dynamic Proxy. Dette betyr at bare eksterne metodesamtaler som kommer inn gjennom proxyen, vil bli snappet opp. Eventuelle selvinnkallingssamtaler vil ikke starte noen transaksjon, selv om metoden har @Transaksjonell kommentar.

En annen advarsel ved bruk av fullmakter er at bare offentlige metoder skal merkes med @Transaksjonell. Metoder for annen synlighet vil rett og slett ignorere kommentaren lydløst, da disse ikke er fullstendig.

Denne artikkelen diskuterer ytterligere proxying fallgruver i detalj her.

5.2. Endre isolasjonsnivået

Vi kan også endre transaksjonsisolasjonsnivået:

@Transactional (isolation = Isolation.SERIALIZABLE)

Merk at dette faktisk har blitt introdusert våren 4.1; hvis vi kjører eksemplet ovenfor før våren 4.1, vil det resultere i:

org.springframework.transaction.InvalidIsolationLevelException: Standard JPA støtter ikke tilpassede isolasjonsnivåer - bruk en spesiell JpaDialect for din JPA-implementering

5.3. Skrivebeskyttede transaksjoner

De lesBare flagg genererer vanligvis forvirring, spesielt når du jobber med JPA; fra Javadoc:

Dette fungerer bare som et hint for selve transaksjonsundersystemet; det vil ikke nødvendigvis forårsake svikt i skrivetilgangsforsøk. En transaksjonsansvarlig som ikke kan tolke det skrivebeskyttede hintet ikke kaste et unntak når du blir bedt om en skrivebeskyttet transaksjon.

Faktum er at Vi kan ikke være sikre på at et innlegg eller en oppdatering ikke vil forekomme når lesBare flagget er satt. Denne oppførselen er avhengig av leverandør, mens JPA er leverandøragnostiker.

Det er også viktig å forstå det de lesBare flagg er bare relevant i en transaksjon. Hvis en operasjon skjer utenfor en transaksjonell kontekst, blir flagget rett og slett ignorert. Et enkelt eksempel på det vil kalle en metode kommentert med:

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

fra en ikke-transaksjonell kontekst - en transaksjon blir ikke opprettet og lesKun flagg vil bli ignorert.

5.4. Transaksjonslogging

En nyttig metode for å forstå transaksjonsrelaterte problemer er finjustering av loggføring i transaksjonspakker. Den aktuelle pakken om våren er “org.springframework.transaction ”, som skal konfigureres med et loggningsnivå på TRACE.

6. Konklusjon

Vi dekket den grunnleggende konfigurasjonen av transaksjonell semantikk ved hjelp av både Java og XML, hvordan du bruker @Transaksjonell og beste praksis i en transaksjonsstrategi.

Som alltid er koden presentert i denne artikkelen tilgjengelig på Github.