50 साल बाद, क्या two-phase locking वही सबसे अच्छा तरीका है जो हम कर सकते हैं?

 (concurrencyfreaks.blogspot.com)
1 पॉइंट द्वारा GN⁺ 2023-10-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख लगभग 50 साल पहले आविष्कृत किए गए सामान्य concurrency control Two-Phase Locking (2PL) की अवधारणा पर चर्चा करता है.
  • 2PL अधिक मजबूत isolation levels, जैसे Serializability और Opacity, प्रदान करता है और कई data items पर होने वाले transactions में उपयोग होता है.
  • लेखक इस बात पर ज़ोर देता है कि 2PL की सरलता और उसके मजबूत isolation levels इसकी मुख्य खूबियाँ हैं.
  • हालांकि, 2PL में read scalability कम होती है और live-lock progress जैसी कमियाँ हैं.
  • लेखक 2PL की समस्याओं को हल करने के लिए एक नया concurrency control, Two-Phase Locking Starvation-Free (2PLSF), प्रस्तुत करता है.
  • 2PLSF बेहतर reader-writer locks का उपयोग करता है और blocking progress के सबसे उच्च रूप, यानी starvation-free transactions, प्रदान करता है.
  • 2PLSF कुछ खास प्रकार के conflicts को हल करने में प्रभावी है, इसलिए कुछ conflicts होने पर भी यह scale कर सकता है.
  • लेखक निष्कर्ष निकालता है कि 2PLSF, 2PL की तुलना में बहुत बड़ा सुधार है, और इसकी तुलना jackhammer और pickaxe के अंतर से करता है.
  • इस लेख में 2PLSF algorithm पर paper और source code के links शामिल हैं, जिन्हें आगे सीखने के लिए देखा जा सकता है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-01
Hacker News राय
  • two-phase locking (2PL) पर चर्चा और पहली बार विकसित किए जाने के 50 साल बाद भी इसकी प्रासंगिकता पर एक लेख।
  • एक कमेंटर बताता है कि वह इस विषय में शुरुआती है और distributed microservices architecture के लिए आसानी से deploy की जा सकने वाली consistency solution ढूंढ रहा है।
  • वही कमेंटर multi-threaded multiprocessing environment में non-determinism को test करने वाला Python code साझा करता है।
  • एक अन्य कमेंटर सुझाव देता है कि पहले यह सोचना चाहिए कि locking algorithm की ज़रूरत है भी या नहीं, और concurrency तथा locking कम करने के लिए requests को batch करने का सुझाव देता है।
  • यह सवाल उठाया गया है कि नया approach, जो serializable snapshot isolation (SSI) के improved version of 2PL के रूप में प्रचारित है, उससे तुलना में कैसा है।
  • एक कमेंटर सुझाव देता है कि सभी प्रकाशित links के लिए केवल HTTPS अनिवार्य करने वाली नई Hacker News policy होनी चाहिए।
  • लेखक के 2PLSF पर paper का link साझा किया गया है, जिसमें दावा किया गया है कि यही वह रूप है जैसा 2PL को मूल रूप से होना चाहिए था।
  • atomic operations की scalability बेहतर करने के लिए random queueing जोड़ने का सुझाव दिया गया है।
  • यह सवाल उठाया गया है कि Wait-Or-Die approach में transaction ID लेना और जोड़ना ज़रूरी है या नहीं, और इसके बजाय thread ID या random number इस्तेमाल करने का सुझाव दिया गया है।
  • एक कमेंटर कहता है कि वह read-only transactions के संदर्भ में relaxed AVL tree वाली आखिरी figure को समझ नहीं पाया।
  • loosely coupled API calls के संदर्भ में 2PL की applicability पर सवाल उठाया गया है।
  • यह बात उठाई गई है कि ज़्यादातर write transactions को कई contended objects पर consistent reads चाहिए होती हैं, लेकिन वास्तविक write अक्सर केवल एक या दो objects पर होती है; और पूछा गया है कि क्या 2PL इसका समाधान करता है।