क्या मुझे दिए गए परिदृश्य में UPDATE ऑपरेशन में एक साथ अनुरोध के बारे में चिंता करने की आवश्यकता है

Question

इस परिदृश्य की कल्पना करें, मेरे पास ऐसी वेबसाइट है जो उपयोगकर्ताओं को अपनी वस्तुओं को बेचने या विज्ञापनों पर क्लिक करने या जो भी मेरी उपयोगकर्ता तालिका होगी, गतिविधि के साथ क्रेडिट प्राप्त करती है इस

users : id , username , credit 
     15 , alex  , 1000 
     16 , jack  , 1500 

की तरह कुछ तो अब उन भुगतान के कुछ प्रकार में अपने क्रेडिट को वापस लेने का अनुरोध कर सकते हैं मेरी तात्पर्य तालिका इस

withdraws : 
id , user_id , amount 
1 , 15  , 500 
2 , 16  , 100 

मैं अपने क्रेडिट से राशि वापस लेने घटाना है की तरह कुछ होगा .. मुझे ट्रिगर के साथ ऐसा करना पसंद है

CREATE TRIGGER withdraw 
    BEFORE INSERT 
    ON withdraws 
    FOR EACH ROW 
BEGIN 

    UPDATE users SET credit = credit-NEW.amount WHERE id = NEW.user_id; 
END $$ 

और यह सुनिश्चित करें उन नहीं कर सकते वापस लेने की प्रक्रिया में नकारात्मक क्रेडिट के साथ खत्म हो मैं इस ट्रिगर होता है (अभिशाप के रूप में अच्छी तरह मैं कोड तर्क में इस की जांच करेंगे)

CREATE TRIGGER update_user 
    BEFORE UPDATE 
    ON users 
    FOR EACH ROW 
BEGIN 

    IF NEW.credit < 0 THEN 
      SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'invalid credit error'; 
    END IF; 


END $$ 

अब बनाने के लिए मेरा सवाल यह है कि, क्या यह जानबूझकर संभव है कि कोई व्यक्ति किसी प्रकार की सर्वर त्रुटि को एक ही समय में एकाधिक निकासी अनुरोध भेजता है, और उसके क्रेडिट से अधिक वापस लेता है .... और यदि ऐसा है तो मैं इसे कैसे रोक सकता हूं?

क्या मुझे प्रत्येक वापसी सम्मिलन या इस तरह से कुछ भी पहले उपयोगकर्ता तालिका को लॉक करने की आवश्यकता है?

अद्यतन: अगर im उपयोगकर्ता पंक्ति ताला और पूरे ऑपरेशन के लिए लेन-देन आवरण का उपयोग करने जा ... उचित लगता है, लेकिन कैसे ट्रिगर में फिट बैठता है करता है? मेरा मतलब है कि मुझे लेनदेन शुरू करना है और इसे कोड में समाप्त करना/प्रतिबद्ध करना है (क्योंकि मैं संग्रहीत प्रक्रियाओं से नफरत करता हूं और कभी उनका उपयोग नहीं करता) क्या इसका मतलब है कि मुझे ट्रिगर छोड़ना है और कोड में घटाव भी करना है या किसी भी तरह ट्रिगर होता है विभिन्न प्लेटफार्म/जगह

Answer 1

में शुरू/निष्पादन के बावजूद लेनदेन के अंदर मैं इरादे ताले के माध्यम से इसे हल कर दूंगा। मैंने लिखा एक उदाहरण here देखें। ट्रांज़ेक्शन खंड के लाइन 1 से लाइन 5 के साथ-साथ अन्य प्रासंगिक जानकारी के बीच क्या होता है, वहां एक कथा है।

आप स्वाभाविक रूप से है कि उदाहरण की तरह एक incrementor नहीं मिल रहा है। इसके बजाय, आपका कोड जितना तेज़ हो सके उतना तेज़ अपडेट करेगा और कमेट करेगा।

कि कोड सिर्फ एक संग्रहीत proc में कहीं भी हो सकती है। यह हो सकता है और घटना या एक ट्रिगर। डीबी इंजन (जैसे आईएनएनओडीबी) यह सुनिश्चित करने के लिए आपका तंत्र है कि एक ही समय में दो लोग उस LOCK के अंदर नहीं जा सकते हैं। आप इससे संबंधित अपना कोड कैसे लिखते हैं आप पर निर्भर है।

Answer 2

यह एक रेस स्थिति कहा जाता है, और प्रश्न में कोड वास्तव में उस के अधीन है। दिलचस्प बात यह है कि, मुझे लगता है कि अगर ट्रिगर्स में और कुछ नहीं होता है, तो यह एक शोषक भेद्यता नहीं है, आप केवल सुरक्षित पक्ष पर भरोसा कर सकते हैं (यह संभव है कि एक वैध निकासी परिणाम एक त्रुटि में हो, लेकिन मुझे लगता है कि यह संभव नहीं है एक अवैध निकासी के परिणामस्वरूप कोई त्रुटि नहीं होती है)।

आपको अभी भी इस तरह से नहीं होना चाहिए, उदाहरण के लिए दौड़ की स्थिति को हटाया जाना चाहिए उदाहरण के लिए ताले (कुछ प्रदर्शन की लागत पर)।