ट्रांजैक्शन आइसोलेशन लेवल समझाइए, और बताइए कि आपका डेटाबेस डिफ़ॉल्ट रूप से कौन सा इस्तेमाल करता है।

चार लेवल हैं: read uncommitted, read committed, repeatable read और serializable, और ये कनकरेंसी के बदले में कुछ anomalies की छूट देते हैं: dirty reads, non repeatable reads, phantom reads और write skew। PostgreSQL का डिफ़ॉल्ट read committed है, जहां हर statement को एक ताज़ा snapshot मिलता है; InnoDB वाला MySQL डिफ़ॉल्ट रूप से repeatable read पर होता है, जहां पूरे ट्रांजैक्शन को एक ही snapshot दिखता है। serializable अकेला ऐसा लेवल है जो गारंटी देता है कि नतीजा किसी न किसी serial क्रम जैसा ही होगा।

ये read uncommitted से शुरू होकर serializable तक जाते हैं, और हर कदम पर एक anomaly हटती है, बदले में कनकरेंसी की कुछ कीमत लगती है। read committed dirty reads रोक देता है, लेकिन हर statement को अपना snapshot मिलता है, इसलिए एक ही ट्रांजैक्शन में वही query दो बार चलाने पर अलग rows आ सकती हैं। repeatable read पूरे ट्रांजैक्शन के लिए एक snapshot पिन कर देता है। serializable इसके ऊपर यह भी गारंटी देता है कि नतीजा वैसा ही होगा जैसा ट्रांजैक्शन एक के बाद एक चलाने पर होता, और Postgres में यह predicate tracking से होता है, इसलिए ब्लॉक करने की जगह वह ट्रांजैक्शन abort भी कर सकता है और आपको retry के लिए तैयार रहना पड़ता है। डिफ़ॉल्ट मायने रखते हैं: Postgres पर read committed है, InnoDB पर repeatable read, और एक से दूसरे पर जाने वाले लोग इससे चौंक जाते हैं। मैंने असल में जो बग झेला वह एक booking टेबल पर write skew था, जहां दो requests ने अलग अलग जांचा कि कोई overlapping reservation नहीं है, दोनों को साफ snapshot दिखा, और दोनों ने insert कर दिया। repeatable read से कुछ नहीं हुआ क्योंकि दोनों ने अलग rows लिखी थीं। हमने इसे serializable और retry से ठीक किया, और बाद में exclusion constraint से, जो सस्ता पड़ता है।