Changes between Version 5 and Version 6 of Transakcii

Timestamp:

04/28/26 01:09:33 (5 days ago)

Author:

213192

Comment:

--

Transakcii

@@ -221 +221 @@
 
 MVCC vs Locking: Главната разлика помеѓу MVCC и класичното заклучување е во тоа што MVCC дозволува читање без блокирање, додека locking пристапот блокира операции. MVCC обезбедува подобра конкурентност, но бара дополнителна меморија за чување на повеќе верзии.
+
+== Примери
+
+1. 2 клуба што истовремено се обидуваат да купат ист играч
+
+Услови: играчот може да оди само во 1 клуб, клубот мора да има буџет, вредноста на играчот се зема „најнова пред трансфер“, се бројат статистики пред трансфер, системот мора да избегне lost update, write skew, deadlock.
+
+Без добра контрола двата клуба го купуваат истиот играч.
+{{{
+SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
+
+BEGIN;
+
+-- 1. LOCK PLAYER 
+SELECT current_club_id
+FROM players
+WHERE player_id = 65
+FOR UPDATE;
+
+-- 2. LOCK BUYING CLUB
+SELECT budget
+FROM clubs
+WHERE club_id = 10
+FOR UPDATE;
+
+-- 3. CHECK: дали веќе е трансфериран?
+-- ако current_club_id = 10 → ROLLBACK
+
+-- 4. CHECK: доволен буџет
+-- ако budget < 5000000 → ROLLBACK
+
+-- 5. MVCC READ (не блокира)
+-- најнова вредност пред трансфер
+SELECT market_value_in_eur
+FROM player_valuations
+WHERE player_id = 65
+  AND date <= CURRENT_DATE
+ORDER BY date DESC
+LIMIT 1;
+
+-- 6. COUNT активности (MVCC snapshot)
+SELECT COUNT(*)
+FROM appearances
+WHERE player_id = 65
+  AND date < CURRENT_DATE;
+
+SELECT COUNT(*)
+FROM game_events
+WHERE player_id = 65
+  AND date < CURRENT_DATE;
+
+-- 7. UPDATE буџет
+UPDATE clubs
+SET budget = budget - 5000000
+WHERE club_id = 10;
+
+-- 8. TRANSFER
+UPDATE players
+SET current_club_id = 10
+WHERE player_id = 65;
+
+-- 9. LOG transfer
+INSERT INTO transfers(player_id, from_club, to_club, transfer_fee, transfer_date)
+VALUES (65, 5, 10, 5000000, CURRENT_DATE);
+
+COMMIT;
+}}}
+
+MVCC не блокираат туку читаат snapshots од податоци. Row-level locking го заклучува само дадениот ред, а seriaziable спречува write skew. Овој пример демонстрира реален конкурентен систем каде повеќе трансакции се обидуваат да модифицираат исти ресурси.
+
+2. Трансфер со специфични барања
+
+Клуб сака да купи играч но не смее да има повеќе од 25 играчи, не смее да има повеќе од 5 играчи со > 20 goals, се зема form (последни настапи) пред трансфер, повеќе трансакции можат истовремено да купуваат играчи.
+
+Проблемот тука е што ако имаме 2 трансакции, и двете мислат дека има место и ако не контролираме и двете ќе додадат играч и ќе се наруши условот.
+
+{{{
+SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
+
+BEGIN;
+
+-- 1. LOCK PLAYER
+SELECT current_club_id
+FROM players
+WHERE player_id = 80
+FOR UPDATE;
+
+-- 2. LOCK CLUB
+SELECT club_id
+FROM clubs
+WHERE club_id = 10
+FOR UPDATE;
+
+-- 3. CHECK TOTAL SQUAD SIZE (MVCC snapshot)
+SELECT COUNT(*)
+FROM players
+WHERE current_club_id = 10;
+
+-- ако >= 25 → ROLLBACK
+
+-- 4. CHECK HIGH-SCORING PLAYERS
+SELECT COUNT(*)
+FROM appearances
+WHERE player_current_club_id = 10
+  AND goals > 20;
+
+-- ако >= 5 → ROLLBACK
+
+-- 5. GET PLAYER FORM (MVCC read)
+SELECT AVG(goals)
+FROM appearances
+WHERE player_id = 80
+  AND date > CURRENT_DATE - INTERVAL '6 months';
+
+-- 6. OPTIONAL BUSINESS RULE
+-- ако form < 2 → можеби не купуваме
+
+-- 7. UPDATE PLAYER
+UPDATE players
+SET current_club_id = 10
+WHERE player_id = 80;
+
+-- 8. INSERT TRANSFER
+INSERT INTO transfers(player_id, from_club, to_club, transfer_fee, transfer_date)
+VALUES (80, 3, 10, 8000000, CURRENT_DATE);
+
+COMMIT;
+}}}
+
+Овој пример демонстрира write skew проблем кој не може да се реши со класично заклучување, бидејќи агрегатните проверки не заклучуваат конкретни редови. Затоа се користи SERIALIZABLE изолација која гарантира дека паралелните трансакции нема да доведат до неконзистентна состојба. MVCC овозможува аналитичките операции да се извршуваат без блокирање, додека row-level locking спречува директни конфликти врз исти записи.