இனம் நிலைமைகள்

ஒரு டேட்டாபேஸ் ஒரு டெர்மினலில் தனித்தனியாக எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்வது எளிது, ஆனால் உண்மையான இணைய சூழ்நிலையில் நூற்றுக்கணக்கான "நோட்/பிஎச்பி/கோ" செயல்முறைகள் ஒரே நேரத்தில் கோரிக்கைகளை அனுப்பும். பிரபலமான ரேஸ் நிபந்தனைகள் இங்குதான் பிறக்கின்றன.

"லாஸ்ட் அப்டேட்" பிரச்சனை

இரண்டு த்ரெட்கள் ஒரே பழைய வரிசையைப் படிக்கும்போது, ​​ஜாவாஸ்கிரிப்ட் சர்வரில் சில கணிதங்களைச் செய்து, முடிவைச் சேமிக்க புதுப்பிப்பை மீண்டும் அனுப்பும்போது லாஸ்ட் அப்டேட் நிகழ்கிறது.

காட்சி:

• தயாரிப்பு #5 10 அலகுகளைக் கொண்டுள்ளது.
• பயனர் A ஒன்றை வாங்குகிறார் (சேவையகம் A "10"ஐப் படிக்கிறது, "9"ஐக் கணக்கிடுகிறது).
• அதே மில்லி விநாடியில், A இன் கொள்முதல் COMMIT கட்டத்தை முடிக்கும் முன் B இன்னொன்றை வாங்குகிறார்.
• சர்வர் பி "10"ஐயும் வாசிக்கிறது, "9"ஐக் கணக்கிடுகிறது.
• சர்வர் A UPDATE: set quantity = 9 ஐ அனுப்புகிறது.
• சர்வர் B UPDATE: set quantity = 9 ஐ அனுப்புகிறது.
• இருவரும் எண்ணை வெற்றிகரமாகக் குறைத்ததாக நினைக்கிறார்கள். ஆனால் இறுதி மதிப்பு 8 அலகுகளாக இருந்திருக்க வேண்டும்! ஒரு பாண்டம் வாங்குதல் இழக்கப்பட்டது.

கடுமையான பரிவர்த்தனைகள் இல்லாத தீர்வு (அணு புதுப்பிப்புகள்)

வெளியே கணிதத்தைப் படித்துச் செய்வதற்குப் பதிலாக, புதுப்பித்தலின் போது DB அதைச் செய்யட்டும், இது எப்போதும் ஒத்திசைக்கப்படும்.

-- Wrong
UPDATE products SET stock = 9 WHERE id = 5;

-- Correct and natively thread-safe
UPDATE products SET stock = stock - 1 WHERE id = 5;

மேலும் தீவிர முரண்பாடுகள் (டர்ட்டி ரீட்ஸ் & பேண்டம்ஸ்)

• டர்ட்டி ரீட்: COMMIT மூலம் இதுவரை உறுதிப்படுத்தப்படாத வேறொருவரின் தற்காலிகத் தரவை நீங்கள் படித்துள்ளீர்கள் (திடீரென்று ROLLBACKக்குச் சென்று உங்களைச் செல்லாததாக்கிவிடும்).
• பாண்டம் ரீட்கள்: நீங்கள் அனைத்து வரிசைகளையும் ஸ்கேன் செய்கிறீர்கள், அதே நேரத்தில் இரண்டாவது த்ரெட் புதிய பதிவைச் செருகுகிறது, பின்னர் அதே பரிவர்த்தனையின் போது மற்றொரு ஸ்கேன் செய்து, கணக்கிடப்பட்ட நிதி அறிக்கைகளை சமரசம் செய்து, புதிய பதிவு எங்கும் இல்லாமல் தோன்றியதை நீங்கள் மாயமாகக் காணலாம்.