I datalogi og især i databaser implementeres en transaktion såsom en reservation, et køb eller en betaling via en række operationer, der ændrer databasen fra en tilstand A - før transaktionen - til en senere B-tilstand, og mekanismer tillader denne sekvens skal samtidig være atomær , sammenhængende , isoleret og holdbar ( ACID ).
Størstedelen af hierarkiske såvel som relationelle databasestyringssystemer på markedet gør det muligt at gennemføre atomare, sammenhængende, isolerede og bæredygtige transaktioner. NoSQL- systemer hævder dette.
Begrebet transaktion er baseret på begrebet synkroniseringspunkt ( synkroniseringspunkt ), der repræsenterer en stabil tilstand af det computersystem, der betragtes, især dets data.
Atomicitet En transaktion skal udføres i det hele eller intet, det vil sige fuldstændigt eller slet ikke; Konsistens Datakonsistens skal sikres i alle tilfælde, selv i fejltilfælde, hvor systemet skal vende tilbage til den tidligere konsistente tilstand. Konsistens er etableret af funktionelle regler. Eksempel: En ejendomstransaktion kan tage lang tid. Fra et computersynspunkt betragtes det som en funktionel procedure, der består af flere computertransaktioner (reservation, købsforslag, kompromis, notarialhandling). De mellemliggende faser styres derfor funktionelt via tilstanden af Apartment-objektet. Selvom proceduren er i gang, forbliver systemet mellem hvert trin konsistent. I tilfælde af afbrydelse af proceduren (en slags tilbageførsel af ejendomstransaktionen) sætter de funktionelle regler lejligheden igen på salg. Der er mange proceduremæssige sager, der ikke kan håndteres af en enkelt it-transaktion. Designeren skal specificere de funktionelle regler, der styrer ændringerne i de pågældende objekters tilstand og manuelt styre det ækvivalente af begåelse og tilbageførsel af proceduren Isolering Transaktionen fungerer i en isoleret tilstand, hvor kun den kan se de data, den ændrer, mens den venter på et nyt synkroniseringspunkt; systemet garanterer andre transaktioner, der udføres parallelt på det samme system, synlighed i tidligere data. Dette opnås takket være systemlåsen indstillet af DBMS. Følgende eksempel illustrerer en mere funktionel isolering, der implementerer en applikationslåsning: En aktør placerer en ordre med henblik på en kontekst. Denne sammenhæng må ikke have ændret sig, når han validerer sin ordre, ellers kan ordren miste al sin betydning. For at forhindre, at konteksten ændres, er det muligt at låse den, før du læser den. Men det er ofte en forbruger af computerressourcer og ubelejligt for andre, især hvis refleksion og input varer flere minutter. I ledelsen er det generelt tilstrækkeligt at kontrollere på tidspunktet for opdateringen, at konteksten ikke er ændret: optimistisk kontrolleres isolationen a posteriori; Holdbarhed Når transaktionen er gennemført, er systemet i en holdbar stabil tilstand, enten efter en vellykket transaktionsændring eller efter en fiasko, der resulterer i en tilbagevenden til den tidligere stabile tilstand. Bæredygtighed er ofte involveret i batchbehandling ( batch ) eller asynkron replikering, der producerer emissioner. Downstream-applikationen har ikke ret til at sætte spørgsmålstegn ved den tidligere transaktion, der udstedte begivenheden, ellers ville det betyde, at denne transaktion ikke efterlod systemet i en konsistent tilstand. Upstream-applikationen skal derfor kontrollere alt omhyggeligt, før informationen formidles. Når den funktionelle arkitektur ikke er ren, er det ofte nødvendigt at styre afvisninger. Disse ekstraordinære behandlinger skal derefter specificeres, så afvisningerne genbruges ved en ofte kompleks funktionel procedure. Derfor er vigtigheden af transaktionens konsistens i forhold til hele systemet.For eksempel er der under en computeroperation at overføre penge fra en bankkonto til en anden bankkonto, en opgave at trække penge fra kildekontoen og en indbetaling fra målkontoen. Computerprogrammet, der udfører denne transaktion, vil sikre, at begge operationer kan udføres uden fejl, og i dette tilfælde vil ændringen derefter træde i kraft på begge konti. Hvis dette ikke er tilfældet, annulleres operationen. Begge konti beholder deres oprindelige værdier. Dette garanterer sammenhængen mellem dataene mellem de to konti.
Computertransaktioner bruges i vid udstrækning i DBMS'er.
Denne gamle teknik, udbredt praktiseret med transaktions-skærme , såsom som IBMs CICS , Bulls TDS, Siemens UTM, er nu almindeligt anvendt i web-applikation arkitekturer , og i klient-server -applikationer .
Faktisk ligner intet mere en webside end en synkron skærm:
Problemet i denne driftsform er, at det undertiden tager en sekvens af flere skærme eller sider at udvikle en komplet ACID- transaktion . Det var Merise- metoden, der definerede disse begreber for første gang:
Denne opgave assimileres med en pseudotransaktion, der fra skærmens synspunkt er en teknisk transaktion, men selvfølgelig ikke rigtig funktionel, før sekvensen er færdig.
Men :
Spørgsmål:
Svarene fra de ældste er også de, der anvendes i dag i "nye" teknologier:
Vi forstår hvorfor, hvis vi sætter systemlåse (SGBD) i hele kæden, hvis varighed er ukontrollerbar, ville systemet kollapse. Dette er hele pointen med pseudo-transaktionen. Men strategien for isoleringskontrol er grundlæggende funktionel.
Pseudotransaktionen er derfor ACID, men de funktionelle regler er således, at konsistensen mellem hver pseudotransaktion i en sekvens er garanteret ved fravær af opdatering af databasen.
En veldesignet klient / serverapplikation bruger også pseudotransaktioner, men konteksten styres i klientapplikationen, hvilket fjerner belastningen fra serveren. Det typiske diagram er som følger:
Hvilket giver N + 1 pseudotransaktioner.