दो यूज़र एक ही रिकॉर्ड को एक ही समय एडिट कर रहे हैं। आप कैसे रोकेंगे कि एक चुपचाप दूसरे को overwrite न कर दे?

ज़्यादातर मामलों में optimistic locking इस्तेमाल करें: row को एक version column या timestamp दें, उसे update के predicate में शामिल करें, और अगर zero rows अपडेट हुईं तो मतलब रिकॉर्ड आपके नीचे से बदल चुका है, तो आप conflict लौटा देते हैं। pessimistic locking, यानी छोटे ट्रांजैक्शन के अंदर select for update, तब लें जब conflicts अक्सर होते हों या ऑपरेशन को सुरक्षित तरीके से retry नहीं किया जा सकता। जो आपको हरगिज़ नहीं करना चाहिए वह है बिना किसी जांच के read, modify और write।

गड़बड़ी read modify write है, जहां दोनों requests version एक लोड करती हैं, दोनों पुराने डेटा से हिसाब लगाती हैं और दूसरी write चुपचाप जीत जाती है। मेरा डिफ़ॉल्ट हल optimistic है: हर row पर एक version होता है, update कहता है where id यह हो और version वही हो जो मैंने पढ़ा था, और फिर वह version बढ़ा देता है। अगर update बताता है कि zero rows बदलीं, तो कोई और पहले पहुंच गया और मैं 409 लौटाता हूं, यह दिखावा नहीं करता कि सब ठीक हो गया। जब conflicts कम होते हैं, और आमतौर पर होते ही कम हैं, तब इसकी कोई कीमत नहीं लगती। मैं pessimistic locking पर तब जाता हूं जब contention सच में है या retry मंज़ूर नहीं, जैसे inventory घटाना, जहां मैं उस row पर select for update लेता हूं, एक छोटे ट्रांजैक्शन में जांच और write दोनों कर लेता हूं, और उस ट्रांजैक्शन के अंदर कोई network call नहीं रखता। जिस बात की मुझे सबसे ज़्यादा परवाह है वह यह कि यूज़र को क्या दिखता है। कोरा conflict error बेकार है, इसलिए एक document editor में हम error के साथ मौजूदा version भी लौटाते थे ताकि क्लाइंट काम गंवाने की जगह एक diff दिखा सके।