আগের TCL lesson command কভার করেছে — BEGIN, COMMIT, ROLLBACK, SAVEPOINT। এই lesson কভার করে সেই command-গুলো আসলে কী গ্যারান্টি দেয়, আর কেন একটা database সেই গ্যারান্টির কয়েকটা ভিন্ন level দেয়।
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;দুটি update একসাথে সফল হয়, বা কোনোটাই না — এই money-transfer উদাহরণ কেন transaction আছে তার ক্লাসিক illustration।
| গ্যারান্টি | এর মানে কী |
|---|---|
| Atomicity | একটা transaction-এর পরিবর্তন সবগুলো ঘটে, বা কোনোটাই না — টাকা একটা account থেকে বের হয়ে অন্যটাতে কখনো না পৌঁছানো আংশিক transfer না |
| Consistency | একটা transaction database-কে শুধু একটা বৈধ state থেকে আরেকটাতে move করতে পারে — এরপরও প্রতিটা constraint (আগের lesson থেকে) টিকে থাকে |
| Isolation | Concurrent transaction একে অপরের uncommitted পরিবর্তন দেখে না — নিচে বিস্তারিত কভার করা |
| Durability | একবার commit হলে, একটা পরিবর্তন টিকে থাকে — এমনকি তার ঠিক পরে একটা server crash-ও এটা হারায় না |
একাধিক transaction প্রায়ই একই সময়ে চলে। Isolation ছাড়া, একটা transaction আরেকটার অর্ধেক-শেষ পরিবর্তন পড়তে পারত — একটা "dirty read" — আর rollback হতে যাওয়া data-র ভিত্তিতে একটা সিদ্ধান্ত নিতে পারত।
| Level | যা আটকায় | Trade-off |
|---|---|---|
| Read Uncommitted | কিছুই না — dirty read সম্ভব | সবচেয়ে দ্রুত, সবচেয়ে কম নিরাপদ |
| Read Committed | Dirty read | বেশিরভাগ database-এ default (যেমন PostgreSQL, SQL Server) |
| Repeatable Read | Dirty read + non-repeatable read (transaction-এর মাঝে একটা row বদলে যাওয়া) | MySQL-এর default |
| Serializable | প্রতিটা concurrency সমস্যা — transaction একবারে একটা করে চলার মতো behave করে | সবচেয়ে নিরাপদ, সবচেয়ে ধীর |
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- ... এখানে query সবচেয়ে কড়া isolation-এ চলে ...
COMMIT;Common Mistake
একটা উচ্চতর isolation level স্বয়ংক্রিয়ভাবে সঠিক পছন্দ না — Serializable ভারী concurrent load-এ বেশি transaction fail আর retry দরকার হতে পারে। বেশিরভাগ application database-এর default দিয়ে ভালোভাবে কাজ চলে।