IT transakce

Ve výpočetní technice , zejména v databázích , se transakce , jako je rezervace, nákup nebo platba, provádí prostřednictvím řady operací, které mění databázi ze stavu A - před transakcí - do pozdějšího stavu B a mechanismy vytvářejí je možné získat, že tato sekvence je současně atomová , koherentní , izolovaná a trvanlivá ( ACID ).

Většina hierarchických i relačních systémů správy databází na trhu umožňuje provádět atomické, koherentní, izolované a udržitelné transakce. Systémy NoSQL to tvrdí.

Vlastnosti ACID

Koncept transakce je založen na pojmu synchronizační bod ( synchronizační bod ), který představuje stabilní stav uvažovaného počítačového systému, zejména jeho dat.

Atomicita Transakce musí být provedena zcela nebo vůbec, to znamená zcela nebo vůbec; Konzistence Konzistence dat musí být zajištěna ve všech případech, a to i v případech chyb, kdy se systém musí vrátit do předchozího konzistentního stavu. Konzistence je stanovena funkčními pravidly. Příklad: Realitní transakce může trvat dlouho. Z počítačového hlediska bude považován za funkční postup složený z několika počítačových transakcí (rezervace, návrh nákupu, kompromis, notářský zápis). Mezilehlé fáze jsou proto funkčně spravovány prostřednictvím stavu objektu Apartment. I když postup probíhá, systém mezi jednotlivými kroky zůstává konzistentní. V případě upuštění od postupu (druh odvolání transakce s nemovitostmi), funkční pravidla uvedla byt znovu do prodeje. Existuje mnoho procesních případů, které nelze vyřešit jedinou transakcí IT. Návrhář musí určit funkční pravidla, která řídí změny stavu dotyčných objektů a ručně spravovat ekvivalent potvrzení a odvolání postupu; Izolace Transakce bude fungovat v izolovaném režimu, kde pouze ona uvidí data, která upravuje, zatímco čeká na nový synchronizační bod; systém zaručuje ostatním transakcím prováděným paralelně na stejném systému viditelnost do minulých dat. Toho je dosaženo díky systémovým zámkům nastaveným DBMS. Následující příklad ilustruje funkčnější izolaci implementující zamykání aplikace: Herec umístí objednávku do pohledu kontextu. Tento kontext se nesmí změnit, když ověřuje svou objednávku, jinak může objednávka ztratit veškerý význam. Aby se zabránilo změně kontextu, je možné jej před čtením uzamknout. Často je však spotřebitelem počítačových zdrojů a nepohodlným pro ostatní, zvláště pokud reflexe a vstup trvá několik minut. Ve správě obecně stačí jednoduše zkontrolovat v době aktualizace, že se kontext nezměnil: optimisticky se izolace kontroluje a posteriori; Trvanlivost Po dokončení transakce je systém ve stabilním stabilním stavu, a to buď po úspěšné transakční změně, nebo po selhání, které má za následek návrat do předchozího stabilního stavu. Udržitelnost se často týká dávkového zpracování ( dávkového ) nebo asynchronní replikace, které produkují emise. Následná aplikace nemá právo zpochybňovat předchozí transakci, která událost vydala, jinak by to znamenalo, že tato transakce neopustila systém v konzistentním stavu. Předřazená aplikace proto musí před šířením informací vše pečlivě zkontrolovat. Pokud funkční architektura není čistá, je často nutné řídit odmítnutí. Tato výjimečná ošetření musí být poté specifikována, aby byly zmetky recyklovány často složitým funkčním postupem. Proto je důležitost konzistence transakce ve vztahu k celému systému.

Příklad transakce ve světě bankovnictví

Například během počítačové operace převodu peněz z jednoho bankovního účtu na jiný bankovní účet existuje úkol vybrat peníze ze zdrojového účtu a úkol uložit z cílového účtu. Počítačový program, který provádí tuto transakci, zajistí, že obě operace bude možné provést bez chyby, a v takovém případě se změna projeví na obou účtech. Pokud tomu tak není, operace se zruší. Oba účty si zachovají své původní hodnoty. Tím je zaručena konzistence dat mezi těmito dvěma účty.

Použití v databázích

Počítačové transakce jsou široce používány v DBMS.

Transakční přezdívka

Tato stará technika, široce používaná u transakčních monitorů, jako jsou IBM CICS , BULL's TDS, Siemens UTM, je nyní široce používána v architekturách webových aplikací a v aplikacích klient-server .

Ve skutečnosti nic nevypadá spíš jako webová stránka než synchronní obrazovka:

Problém, který představuje tento provozní režim, spočívá v tom, že vytvoření úplné transakce ACID někdy trvá sekvenci několika obrazovek nebo stránek . Byla to metodika Merise, která poprvé definovala tyto koncepty:

Tento úkol je asimilován na pseudotransakci, která je z pohledu monitoru technickou transakcí, ale samozřejmě není skutečně funkční, dokud není sekvence dokončena.

Ale :

Dotazy:

Odpovědi starších jsou také dnes používanými v „nových“ technologiích:

Chápeme, proč kdybychom nastavili systémové zámky (SGBD) v celém řetězci, jehož trvání je nekontrolovatelné, systém by se zhroutil. To je celý bod pseudo transakce. Strategie kontroly izolace je však v zásadě funkční.

Pseudo transakce je tedy KYSELÁ, ale funkční pravidla jsou taková, že konzistence mezi každou pseudo transakcí v sekvenci je zaručena absencí aktualizace databáze.


Dobře navržená aplikace klient / server také používá pseudotransakce, ale kontext je spravován v klientské aplikaci, což snižuje zátěž serveru. Typický diagram je následující:

Což dává N + 1 pseudo transakce.

Podívejte se také

Poznámky a odkazy

  1. (in) Philip A. Bernstein a Eric Newcomer, Principles of transaction processing , Morgan Kaufmann - 1997 ( ISBN  9781558604155 )
  2. Peter McIntyre a kol., Pro PHP Programming , Apress, strana 127: „Databáze NoSQL, jak název napovídá, nejsou klasickými databázemi SQL a neimplementují vlastnosti ACID. "

Bibliografie