ACID Transactions

Teori

Fire egenskaber der garanterer pålidelige database transactions: Atomicity, Consistency, Isolation, Duration.

Beskrivelse

ACID er et akronym for fire fundamentale egenskaber der garanterer at database transactions er pålidelige og konsistente selv ved fejl eller concurrent access. Atomicity betyder at en transaction enten sker helt eller slet ikke - ingen partial updates. Consistency sikrer at databasen altid er i en valid state før og efter transaktionen. Isolation betyder at concurrent transactions ikke påvirker hinanden. Durability garanterer at committede changes overlever system crashes. ACID er fundamentet for traditionelle relationelle databaser som PostgreSQL og MySQL og er kritisk for applikationer hvor data integritet er afgørende - banking, e-commerce, booking systemer. Dog kommer ACID med performance trade-offs: strikte isolation levels og durability guarantees kan reducere throughput. Moderne systemer balancerer ofte ACID guarantees med performance - NoSQL databaser vælger ofte eventual consistency over strict ACID for bedre skalering.

Problem

Uden ACID garantier kan database operations fejle på upålidelige måder: penge kan forsvinde ved transfers, inventory kan blive negativt, eller to brugere kan booke samme seat. Concurrent access og system crashes kan korruptere data.

Løsning

ACID transaktioner wrapping multiple operations så de behandles som én atomic unit. Databasen bruger write-ahead logging, locking, og MVCC til at enforce ACID properties og sikre data integritet.

Eksempel

-- Bank transfer eksempel uden transaction (FARLIGT!)
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
-- Hvis system crasher HER, er penge væk!
UPDATE accounts SET balance = balance + 500 WHERE account_id = 2;

-- Med ACID transaction (SIKKERT)
BEGIN TRANSACTION;
  -- Atomicity: Begge updates eller ingen
  UPDATE accounts SET balance = balance - 500 
  WHERE account_id = 1;
  
  UPDATE accounts SET balance = balance + 500 
  WHERE account_id = 2;
  
  -- Consistency: Check business rule
  IF (SELECT balance FROM accounts WHERE account_id = 1) < 0 THEN
    ROLLBACK; -- Anuller alt
  ELSE
    COMMIT; -- Gem begge changes permanent
  END IF;
END TRANSACTION;

-- Isolation levels
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
  -- Denne transaction ser ikke uncommitted changes fra andre
  SELECT * FROM products WHERE id = 123 FOR UPDATE;
  -- Lock row så andre må vente
  UPDATE products SET stock = stock - 1 WHERE id = 123;
COMMIT;

-- Durability demonstration
BEGIN TRANSACTION;
  INSERT INTO orders (user_id, total) VALUES (1, 999.99);
  COMMIT; -- Nu garanteres data gemt selv ved system crash
-- Data overlever power failure pga. write-ahead log

Fordele

✓Garanteret data integritet
✓Ingen partial updates eller corrupted state
✓Sikker concurrent access
✓Recovery efter system failures
✓Business logic constraints enforced

Udfordringer

⚠Performance overhead fra locking
⚠Reduceret throughput ved høj concurrency
⚠Kompleksitet i distribuerede systemer
⚠Deadlocks kan forekomme
⚠Ikke altid nødvendigt for alle use cases

Anvendelsesområder

•Finansielle transaktioner og banking
•E-commerce ordre processering
•Booking systemer (hoteller, flybilletter)
•Inventory management
•Multi-user applikationer med concurrent writes

Eksempler fra den virkelige verden

•Bankoverforsler (begge konti opdateres eller ingen)
•Online shopping checkout (inventory, payment, order creation)
•Flight booking (seat allocation må ikke double-book)
•Casino gaming (balance updates må være præcise)
•Medical records (critical data consistency)