IT-transaksjon

I informatikk , og spesielt i databaser , implementeres en transaksjon som en reservasjon, et kjøp eller en betaling via en rekke operasjoner som endrer databasen fra en tilstand A - før transaksjonen - til en senere B-tilstand og mekanismer gjør det er mulig å oppnå at denne sekvensen er samtidig atomær , sammenhengende , isolert og holdbar ( ACID ).

atomisk : sekvensen av operasjoner er udelelig, i tilfelle feil under en av operasjonene, må operasjonssekvensen avbrytes helt ( tilbakestilling ) uavhengig av antall operasjoner som allerede er vellykket.
konsistent : innholdet i databasen på slutten av transaksjonen må være konsistent uten at hver operasjon under transaksjonen gir konsistent innhold. Inkonsekvent sluttinnhold bør forårsake feil og tilbakeføring av alle operasjoner i transaksjonen.
isolert : når to transaksjoner A og B utføres samtidig, er endringene gjort av A verken synlige av B, eller kan endres av B før transaksjonen A er fullført og forpliktet ( forpliktelse ).
holdbar : Når den er validert, må tilstanden til databasen være permanent, og ingen teknisk hendelse (eksempel: krasj ) må kunne forårsake en kansellering av operasjonene som ble utført under transaksjonen.

Flertallet av hierarkiske så vel som relasjonelle databasestyringssystemer på markedet tillater at det gjennomføres atomare, sammenhengende, isolerte og bærekraftige transaksjoner. NoSQL- systemer hevder dette.

De ACID egenskaper

Konseptet med transaksjon er basert på forestillingen om synkroniseringspunkt ( synkroniseringspunkt ) som representerer en stabil tilstand for datasystemet som vurderes, spesielt av dataene.

Atomisitet En transaksjon må gjøres i det hele tatt eller ingenting, det vil si helt eller slett ikke; Konsistens Datakonsistens må sikres i alle tilfeller, selv i feiltilfeller der systemet må gå tilbake til forrige konsistente tilstand. Konsistens er etablert av funksjonelle regler. Eksempel: En eiendomstransaksjon kan ta lang tid. Fra et datasynspunkt vil det bli sett på som en funksjonell prosedyre som består av flere datatransaksjoner (reservasjon, kjøpsforslag, kompromiss, notarialhandling). Mellomstadiene styres derfor funksjonelt via tilstanden til leilighetsobjektet. Selv om prosedyren pågår, forblir systemet konsistent mellom hvert trinn. I tilfelle avvikling av prosedyren (en slags tilbakeføring av eiendomstransaksjonen), legger de funksjonelle reglene leiligheten ut for salg igjen. Det er mange prosessuelle saker som ikke kan håndteres av en enkelt IT-transaksjon. Designeren må spesifisere de funksjonelle reglene som kontrollerer endringene i tilstanden til de aktuelle objektene og manuelt administrere ekvivalenten til forpliktelse og tilbakeføring av prosedyren Isolasjon Transaksjonen fungerer i en isolert modus der bare den kan se dataene den endrer mens den venter på et nytt synkroniseringspunkt; systemet garanterer andre transaksjoner, utført parallelt på det samme systemet, synlighet i tidligere data. Dette oppnås takket være systemlåsene satt av DBMS. Følgende eksempel illustrerer en mer funksjonell isolasjon som implementerer en applikasjonslåsing: En aktør plasserer en ordre med tanke på en kontekst. Denne konteksten må ikke ha endret seg når han validerer bestillingen, ellers kan ordren miste all sin betydning. For å forhindre at konteksten endres, er det mulig å låse den før du leser den. Men det er ofte en forbruker av dataressurser og upraktisk for andre, spesielt hvis refleksjon og innspill varer i flere minutter. I ledelsen er det generelt tilstrekkelig å bare sjekke på tidspunktet for oppdateringen at konteksten ikke har endret seg: optimistisk blir isolasjonen kontrollert a posteriori; Varighet Når transaksjonen er fullført, er systemet i en holdbar stabil tilstand, enten etter en vellykket transaksjonsendring eller etter en feil som resulterer i en retur til den forrige stabile tilstanden. Bærekraft er ofte involvert i batchbehandling ( batch ) eller asynkron replikering som gir utslipp. Nedstrømsapplikasjonen har ikke rett til å stille spørsmål ved den forrige transaksjonen som utstedte hendelsen, ellers vil dette bety at denne transaksjonen ikke etterlot systemet i en konsistent tilstand. Oppstrømsapplikasjonen må derfor sjekke alt nøye før informasjonen formidles. Når den funksjonelle arkitekturen ikke er ren, er det ofte nødvendig å håndtere avvisninger. Disse eksepsjonelle behandlingene må deretter spesifiseres slik at avvisninger resirkuleres ved en ofte kompleks funksjonell prosedyre. Derfor er betydningen av konsistensen av transaksjonen i forhold til hele systemet.

Eksempel på transaksjoner i bankverdenen

For eksempel under en datoperasjon med overføring av penger fra en bankkonto til en annen bankkonto, er det en oppgave å ta ut penger fra kildekontoen og en innskuddsoppgave fra målkontoen. Dataprogrammet som utfører denne transaksjonen vil sikre at begge operasjonene kan utføres uten feil, og i dette tilfellet vil endringen tre i kraft på begge kontoer. Hvis dette ikke er tilfelle, avbrytes operasjonen. Begge kontoene beholder sine opprinnelige verdier. Dette garanterer konsistensen av dataene mellom de to kontoene.

Bruk i databaser

Datatransaksjoner er mye brukt i DBMS.

Transaksjonelt kallenavn

Denne gamle teknikk, i stor utstrekning med transaksjons skjermer , slik som IBM CICS , Bulls TDS, Siemens UTM, er nå mye brukt i web-applikasjon arkitekturer , og i klient-server -applikasjoner .

Faktisk ser ingenting mer ut som en webside enn en synkron skjerm:

oppføringen lagres lokalt etter noen grunnleggende overflatekontroller;
og når du trykker "Enter" sendes alle de angitte feltene globalt til den sentrale serveren som analyserer, behandler og deretter returnerer et nytt skjermbilde eller en ny side.

Problemet i denne driftsmåten er at det noen ganger tar en sekvens på flere skjermer eller sider for å utvikle en fullstendig ACID- transaksjon . Det var Merise- metoden som definerte disse konseptene for første gang:

Sekvensen kalles “Funksjonell prosedyre”;
Behandling mellom to skjermer eller sider kalles en “oppgave”.

Denne oppgaven assimileres med en pseudotransaksjon som fra skjermens synspunkt er en teknisk transaksjon, men selvfølgelig ikke veldig funksjonell før sekvensen er ferdig.

Men :

Det er ikke mulig å bruke systemlåsemekanismene for å sikre isolasjon av en kjede, ellers vil systemet låse seg selv fordi mange brukere får tilgang til de samme ressursene samtidig. Klient- / serverapplikasjoner som bruker DBMS-låsemekanismer, faller ofte med en belastning på 20 brukere på grunn av dette.
Det er ikke mulig å returnere alle innhentede kontekstuelle data (bruker, rettigheter, data som allerede er skrevet inn eller lest) på skjermen eller siden, ellers blir utvekslingene for tunge.

Spørsmål:

Hvordan garanterer du isolasjonen av en kjede av pseudotransaksjoner?
Hvordan håndtere sammenhengen mellom to pseudotransaksjoner?

Svarene fra de eldste er også de som brukes i dag i "nye" teknologier:

Du må administrere en kontekst ved å "lenke" på serveren: i DBMS, en fil eller i minnet.
Denne konteksten må ha en identifikator, og en begrenset levetid, det vil si selvdestruksjon etter en viss tid.
Objektene i databasen er merket med en dato-tid (tidsstempel) som endres med hver oppdatering.
De nødvendige objektene blir lest under de forskjellige oppgavene.
Den nyttige informasjonen som er skaffet holdes i sammenhengen: avlesninger, oppføringer, meldinger, spesielt DateTime for hvert objekt som blir lest, og isolasjonen vi skal sjekke etterpå.
Ingen oppdatering av det vedvarende systemet (databasen) gjøres bortsett fra den siste oppgaven.
I løpet av den siste oppgaven utfører programmet sine funksjonelle integritetskontroller, og kontrollerer dataisolasjonen ved å sammenligne DateTime av objektene i konteksten med det som er lest i databasen før oppdateringen gjøres: oppdater der DateTime = DateTime -lue. Denne oppgaven sikrer strømens syreegenskaper.
Åpenbart, hvis en annen bruker har oppdatert et objekt som må forbli isolert, må kjedingen startes på nytt. I ledelsen kan vi ofte organisere oss slik at denne saken er sjelden.
Hvis det var nødvendig å reservere objektet når du leste det, ville det være tilstrekkelig å legge inn DateTime, det på slutten av reservasjonen, for eksempel "Nå" + 1/4 time. I dette tilfellet, når du leser, må du forsikre deg om at ingen har reservert objektet ved å kontrollere at DateTime er mye mindre enn "Nå".
Det kan være nødvendig å kontrollere at et objekt som ikke er oppdatert ikke har flyttet. I dette tilfellet forblir prinsippet det samme: vi sjekker DateTime.
Det kan være tilstrekkelig å bare sjekke ett dataelement for objektet. I dette tilfellet vil vi begrense testen til disse dataene uten å bekymre oss for DateTime.
I en database er 50% av objektene av typen "kodetabell", og oppdateres periodisk av en sentralisert administrator. Det er ikke nyttig å kontrollere isolasjonen av disse dataene.
Du må vite hvordan du skal vurdere risikoen for tap av isolasjon under kjetting, og begrense deg til å bare sjekke hva som er nyttig.
I kjedens siste oppgave setter pseudotransaksjonen normalt og automatisk alle vanlige systemlåser som garanterer teknisk isolering av alle oppdaterte data. Denne behandlingen varer bare noen få hundredeler av et sekund, så innholdet med andre brukere er lite.

Vi forstår hvorfor hvis vi setter systemlås (SGBD) i hele kjeden, hvis varighet er ukontrollerbar, ville systemet kollapse. Dette er hele poenget med pseudotransaksjonen. Men strategien for isolasjonskontroll er grunnleggende funksjonell.

Pseudotransaksjonen er derfor SUR, men de funksjonelle reglene er slik at konsistensen mellom hver pseudotransaksjon i en sekvens er garantert ved fravær av oppdatering av databasen.

En godt designet klient / serverapplikasjon bruker også pseudotransaksjoner, men konteksten håndteres i klientapplikasjonen, noe som tar belastningen på serveren. Det typiske diagrammet er som følger:

N leste forespørsler
Operasjoner i minnet til klientapplikasjonen
1 oppdateringsforespørsel for alle modifiserte objekter med en posteriori isolasjonskontroll

Noe som gir N + 1 pseudotransaksjoner.

Se også

Merknader og referanser

(in) Philip A.Bernstein og Eric Newcomer, prinsipper for transaksjonsbehandling , Morgan Kaufmann - 1997 ( ISBN 9781558604155 )
Peter McIntyre et al., Pro PHP Programming , Apress, side 127: “NoSQL-databaser, som navnet antyder, er ikke klassiske SQL-databaser og implementerer ikke ACID-egenskapene. "

Bibliografi

Jérôme Besancenot, Michèle Cart, Jean Ferrié, Rachid Guerraoui, Philippe Pucheral og Bruno Traverson, Transactional systems: concept , standards and products , Ed. Hermes, koll. "Informatikk",Oktober 1997( ISBN 2-86601-645-9 )
(no) James Gray og Andreas Reuter, Transaction Processing - Concepts and Techniques , Morgan Kaufmann, 1993 ( ISBN 1-55860-190-2 )