Database transaction ও ACID সহজ ভাষায়

Transaction হলো database অপারেশনের একটি গুচ্ছ, যা একক ইউনিট হিসেবে গণ্য: সব সফল হয়, নয়তো কিছুই কার্যকর হয় না।

ক্লাসিক উদাহরণ: ট্রান্সফার

অ্যাকাউন্ট A থেকে B-তে ৫০০ সরান:

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 'A';
UPDATE accounts SET balance = balance + 500 WHERE id = 'B';
COMMIT;

প্রথম UPDATE-এর পর server crash করলে টাকা উধাও হতো। Transaction থাকলে database প্রথম ধাপ পূর্বাবস্থায় ফেরায়। আপনার কোড সমস্যা ধরলে COMMIT-এর বদলে ROLLBACK চালাতে পারে।

ACID

Atomicity। সব, নয়তো কিছুই নয়। Transaction কখনো অর্ধেক প্রয়োগ হয় না।

Consistency। Transaction database-কে একটি বৈধ অবস্থা থেকে আরেকটিতে নেয়, constraint, foreign key ও unique key-র মতো নিয়ম মেনে। (অ্যাপকেও নিজের business নিয়ম রাখতে হবে, যেমন "balance ঋণাত্মক হবে না", আদর্শভাবে CHECK constraint দিয়ে।)

Isolation। একসাথে চলা transaction এমনভাবে বিভ্রান্তিকর হস্তক্ষেপ করে না, যেন একটি একটি করে চলছে। শক্তি ঠিক করা যায় (isolation level পর্ব দেখুন)।

Durability। COMMIT-এর পর crash বা বিদ্যুৎ গেলেও data টিকে থাকে। Database এটি write-ahead log (WAL) দিয়ে করে: পরিবর্তন আগে disk-এর log-এ লেখা হয়।

Autocommit

অনেক টুল ডিফল্টে প্রতিটি statement-কে আলাদা transaction হিসেবে চালায়। Statement গুচ্ছ করতে স্পষ্টভাবে transaction শুরু করতে হয় (BEGIN/START TRANSACTION) বা আপনার library-র transaction helper ব্যবহার করতে হয়।

ভালোভাবে ব্যবহার

• ছোট রাখুন। দীর্ঘ transaction lock ধরে রাখে, অন্যদের আটকায়, এবং পরিষ্কারের কাজ ধীর করে। মাঝখানে user-এর অপেক্ষা বা বাইরের API call করবেন না।
• ভেতরে শুধু database-এর কাজ। ভেতরে ইমেইল পাঠিয়ে rollback করলে ইমেইল চলে গেছে। Side effect commit-এর পরে করুন।
• Error সামলান: ব্যর্থতায় rollback করুন, আর conflict হলে পুরো transaction retry করুন।
• দরকারে lock: SELECT ... FOR UPDATE একটি row পড়ে transaction শেষ হওয়া পর্যন্ত lock করে, lost update এড়াতে।
• Deadlock থেকে সাবধান: দুই transaction একে অপরের জন্য অপেক্ষা করছে। সামঞ্জস্যপূর্ণ ক্রমে row lock করুন ও retry-র জন্য প্রস্তুত থাকুন।

Service জুড়ে transaction

Transaction একটি database ঢাকে। একাধিক service জুড়ে saga বা outbox pattern-এর মতো অন্য পদ্ধতি লাগে।

সব database নয়

বেশিরভাগ relational database পূর্ণ ACID দেয়। অনেক NoSQL দুর্বল গ্যারান্টি দেয় বা transaction একক ডকুমেন্টে সীমিত রাখে। ভরসা করার আগে যাচাই করুন।

মূল কথা: সম্পর্কিত পরিবর্তন transaction-এ মুড়ুন, ছোট রাখুন, side effect commit-এর পরে করুন, এবং retry-র জন্য প্রস্তুত থাকুন।

---

Backend ও Database সিরিজ, পর্ব ১ (SQL ও transaction): 3 নম্বর (মোট 4)। আগের লেখা: Database index: B-tree কীভাবে query দ্রুত করে.