MySQL / InnoDB में लेनदेन के लिए समय सीमा निर्धारित करना


11

इस संबंधित प्रश्न से यह उछला , जहां मैं जानना चाहता था कि दो लेन-देन को कैसे एक तुच्छ मामले में क्रमिक रूप से होने के लिए मजबूर करना है (जहां दोनों केवल एक पंक्ति पर काम कर रहे हैं)। मुझे एक उत्तर मिला- SELECT ... FOR UPDATEदोनों लेन-देन की पहली पंक्ति के रूप में उपयोग करें - लेकिन इससे एक समस्या पैदा होती है: यदि पहला लेनदेन कभी भी प्रतिबद्ध या वापस नहीं हुआ है, तो दूसरा लेनदेन अनिश्चित काल के लिए अवरुद्ध हो जाएगा। innodb_lock_wait_timeoutचर सेकंड जिसके बाद ग्राहक दूसरी लेन-देन करने की कोशिश कर बताया जाएगा "क्षमा करें, पुन: प्रयास करें" ... लेकिन जहाँ तक मैं बता सकता हूँ, वे अगले सर्वर रिबूट तक फिर से प्रयास करने होगी की संख्या निर्धारित करता है। इसलिए:

  1. निश्चित रूप से ROLLBACKयदि कोई लेन-देन हमेशा के लिए हो रहा है तो मजबूर करने का एक तरीका होना चाहिए ? क्या मुझे ऐसे लेनदेन को मारने के लिए डेमॉन का उपयोग करना चाहिए, और यदि ऐसा है, तो ऐसा डेमन कैसा दिखेगा?
  2. यदि कोई कनेक्शन लेन-देन wait_timeoutया interactive_timeoutमध्य लेन-देन द्वारा मारा जाता है , तो क्या लेनदेन वापस आ गया है? क्या कंसोल से इसका परीक्षण करने का कोई तरीका है?

क्लैरिफिकेशन : innodb_lock_wait_timeoutसेकंड की संख्या निर्धारित करता है जो एक लेन-देन ताला खोलने के लिए जारी होने का इंतजार करेगा; मैं जो चाहता हूं, वह ताला खोलने के लिए मजबूर करने का एक तरीका है

अपडेट 1 : यहां एक सरल उदाहरण है, जो दर्शाता है कि innodb_lock_wait_timeoutयह सुनिश्चित करने के लिए पर्याप्त क्यों नहीं है कि दूसरा लेनदेन पहले से अवरुद्ध नहीं है:

START TRANSACTION;
SELECT SLEEP(55);
COMMIT;

की डिफ़ॉल्ट सेटिंग के साथ innodb_lock_wait_timeout = 50, यह लेनदेन 55 सेकंड के बाद त्रुटियों के बिना पूरा होता है। और यदि आप लाइन UPDATEसे पहले जोड़ते हैं SLEEP, तो दूसरे क्लाइंट SELECT ... FOR UPDATEसे उसी लेन-देन की कोशिश करने वाला दूसरा ट्रांजेक्शन शुरू करें , यह दूसरा ट्रांजैक्शन है जो कई बार आउट हुआ, सो नहीं।

मैं जिस चीज की तलाश कर रहा हूं, वह इस लेन-देन के आराम देने वाली नींद को खत्म करने का एक तरीका है।

अद्यतन 2 : हॉबोव्वे की चिंताओं के जवाब में कि ऊपर का उदाहरण कितना यथार्थवादी है, यहां एक वैकल्पिक परिदृश्य है: एक डीबीए एक लाइव सर्वर से जुड़ता है और चलता है

START TRANSACTION
SELECT ... FOR UPDATE

जहां दूसरी पंक्ति एक पंक्ति को लॉक करती है जिसे एप्लिकेशन अक्सर लिखता है। तब डीबीए बाधित होता है और लेन-देन समाप्त करना भूल जाता है। जब तक पंक्ति को अनलॉक नहीं किया जाता है तब तक अनुप्रयोग रुक जाता है। मैं उस समय को कम से कम करना चाहूंगा जो इस गलती के परिणामस्वरूप एप्लिकेशन अटक गया है।


आपने अपने प्रश्न को अपने प्रारंभिक प्रश्न के साथ पूरी तरह से संघर्ष करने के लिए अपडेट किया है। आप बोल्ड में कहते हैं "यदि पहला लेन-देन कभी भी प्रतिबद्ध या वापस नहीं हुआ है, तो दूसरा लेनदेन अनिश्चित काल तक अवरुद्ध रहेगा।" आप इसे अपने नवीनतम अपडेट से नापसंद करते हैं: "यह दूसरी बार होने वाला लेनदेन है, न कि वह जो सो गया था।" - गंभीरता से ?!
होबोड्वे

मुझे लगता है कि मेरे phrasing स्पष्ट हो सकता था। "अनिश्चित काल के लिए अवरुद्ध", मेरा मतलब था कि दूसरा लेन-देन एक त्रुटि संदेश के साथ होगा जो कहता है कि "लेनदेन को पुनः आरंभ करने का प्रयास करें"; लेकिन ऐसा करना फलदायी होगा, क्योंकि यह फिर से समाप्त हो जाएगा। इसलिए दूसरा लेन-देन अवरुद्ध है - यह कभी पूरा नहीं होगा, क्योंकि यह समय समाप्त कर देगा।
ट्रेवर बर्नहैम

@ ट्रेवर: आपका वाक्यांश पूरी तरह से स्पष्ट था। आपने पूरी तरह से अलग चीज़ पूछने के लिए बस अपना प्रश्न अपडेट किया है, जो कि बेहद खराब है।
होबोड्वे

सवाल हमेशा एक ही रहा है: यह एक समस्या है कि दूसरा लेनदेन अनिश्चित काल के लिए अवरुद्ध हो जाता है जब पहला लेनदेन कभी भी प्रतिबद्ध या वापस नहीं किया जाता है। मैं ROLLBACKपहले लेन-देन पर जोर देना चाहता हूं अगर इसे nपूरा होने में सेकंड से अधिक समय लगता है । क्या ऐसा करने का कोई तरीका है?
ट्रेवर बर्नहैम

1
@TrevorBurnham मुझे आश्चर्य है कि MYSQLइस परिदृश्य को रोकने के लिए कॉन्फ़िगरेशन क्यों नहीं है। क्योंकि यह क्लाइंट की गैर-जिम्मेदारी के कारण सर्वर हैंग करने के लिए स्वीकार्य नहीं है। मुझे आपके प्रश्न को समझने में कोई कठिनाई नहीं हुई यह भी बहुत प्रासंगिक है।
डिनोप पालोली

जवाबों:


10

आधे से ज्यादा यह धागा सर्वरफॉल्ट पर सवाल पूछने के बारे में लगता है। मुझे लगता है कि सवाल समझ में आता है और यह बहुत आसान है: आप स्वचालित रूप से एक रुके हुए लेन-देन को कैसे रोल करते हैं?

एक समाधान, यदि आप पूरे कनेक्शन को मारने के लिए तैयार हैं, तो प्रतीक्षा_टाइम / इंटरैक्टिव_टाइमआउट सेट करना है। Https://stackoverflow.com/questions/9936699/mysql-rollback-on-transaction-with-lost-disconnected-connection देखें ।


3

चूंकि आपका प्रश्न यहां सर्वरफॉल्ट पर पूछा गया है, इसलिए यह मान लेना तर्कसंगत है कि आप एक MySQL समस्या के लिए एक MySQL समाधान की मांग कर रहे हैं, विशेष रूप से ज्ञान के दायरे में कि एक सिस्टम एडमिनिस्ट्रेटर और / या DBA में विशेषज्ञता होगी। जैसे, निम्न। अनुभाग आपके प्रश्नों को संबोधित करता है:

यदि पहला लेन-देन कभी भी प्रतिबद्ध या वापस नहीं हुआ है, तो दूसरा लेनदेन अनिश्चित काल के लिए अवरुद्ध हो जाएगा

नहीं, यह नहीं होगा। मुझे लगता है कि आप समझ नहीं रहे हैं innodb_lock_wait_timeout। यह वही करता है जो आपको चाहिए।

यह मैनुअल में बताई गई त्रुटि के साथ लौटेगा:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
  • परिभाषा के अनुसार, यह अनिश्चित नहीं है । यदि आपका एप्लिकेशन बार-बार पुन: कनेक्ट और ब्लॉक हो रहा है, तो आपका एप्लिकेशन "अनिश्चित काल तक अवरुद्ध" है, लेन-देन नहीं। दूसरा लेन-देन innodb_lock_wait_timeoutसेकंड के लिए निश्चित रूप से ब्लॉक करता है ।

डिफ़ॉल्ट रूप से, लेन-देन वापस नहीं किया जाएगा। इस त्रुटि को कैसे संभालना है, क्या फिर से कोशिश कर रहा है या वापस रोल करना है यह तय करना आपके एप्लिकेशन कोड की जिम्मेदारी है।

यदि आप स्वचालित रोलबैक चाहते हैं, तो यह भी मैनुअल में समझाया गया है:

वर्तमान लेनदेन वापस नहीं किया गया है। (संपूर्ण लेन-देन रोल बैक करने के लिए, --innodb_rollback_on_timeoutविकल्प के साथ सर्वर शुरू करें ।


पुन: आपके कई अपडेट और टिप्पणियां

सबसे पहले, आपने अपनी टिप्पणियों में कहा है कि आपका "मतलब" यह कहना है कि आप पहले लेनदेन को अनिश्चित काल के लिए अवरुद्ध करने का एक तरीका चाहते हैं । यह आपके मूल प्रश्न से स्पष्ट नहीं है और "यदि पहला लेन-देन कभी भी प्रतिबद्ध या लुढ़का हुआ नहीं है, तो दूसरा लेन-देन अनिश्चित काल तक अवरुद्ध रहेगा"।

बहरहाल, मैं उस सवाल का जवाब भी दे सकता हूं। MySQL प्रोटोकॉल में "क्वेरी टाइमआउट" नहीं है। इसका अर्थ है कि आप पहले अवरुद्ध लेनदेन को टाइमआउट नहीं कर सकते। जब तक यह समाप्त नहीं हो जाता है, तब तक आपको इंतजार करना चाहिए या सत्र को मारना चाहिए। जब सत्र को मार दिया जाता है तो सर्वर स्वचालित रूप से लेनदेन को वापस ले लेगा।

एकमात्र अन्य विकल्प एक mysql पुस्तकालय का उपयोग या लिखना होगा जो गैर-अवरुद्ध I / O का उपयोग करता है जो आपके आवेदन को N सेकंड के बाद क्वेरी बनाने वाले थ्रेड / फोर्क को मारने की अनुमति देगा । ऐसी लाइब्रेरी का कार्यान्वयन और उपयोग सर्वरफॉल्ट के दायरे से परे है। यह StackOverflow के लिए एक उपयुक्त प्रश्न है ।

दूसरे, आपने अपनी टिप्पणियों में निम्नलिखित कहा है:

मैं वास्तव में एक परिदृश्य के साथ अपने प्रश्न में अधिक चिंतित था जिसमें ग्राहक ऐप हैंग (एक अनंत लूप में फंस जाता है) एक लेनदेन के दौरान एक से अधिक होता है, जिसमें लेनदेन MySQL के अंत में एक लंबा समय लगता है।

यह आपके मूल प्रश्न में बिल्कुल स्पष्ट नहीं था, और अभी भी नहीं है। टिप्पणी में इस महत्वपूर्ण टिडबिट को साझा करने के बाद ही आपको यह पता चल सकता है।

यदि यह वास्तव में समस्या है जिसे आप हल करने की कोशिश कर रहे हैं, तो मुझे डर है कि आपने इसे गलत फोरम पर पूछा है। आपने एक एप्लिकेशन स्तर प्रोग्रामिंग समस्या का वर्णन किया है जिसके लिए एक प्रोग्रामिंग समाधान की आवश्यकता होती है, जो कि MySQL प्रदान नहीं कर सकता है, और इस समुदाय के दायरे से बाहर है। आपका नवीनतम उत्तर प्रश्न का उत्तर देता है "मैं रूबी प्रोग्राम को असीम रूप से लूपिंग से कैसे रोकूँ?"। यह प्रश्न इस समुदाय के लिए ऑफ-टॉपिक है और इसे StackOverflow पर पूछा जाना चाहिए ।


क्षमा करें, लेकिन यह सच है जब लेन-देन एक ताला के लिए इंतजार कर रहा है (जैसा कि नाम और innodb_lock_wait_timeoutसुझाव के दस्तावेज ), यह उस स्थिति में नहीं है जिसे मैंने पेश किया है: जहां ग्राहक को लटका या दुर्घटनाग्रस्त हो जाता है इससे पहले कि वह बदलाव करे COMMITया ROLLBACK
ट्रेवर बर्नहैम

@ ट्रेवर: आप बस गलत हैं। यह आपके अंत पर परीक्षण करने के लिए तुच्छ है। मैंने बस अपने अंत पर इसका परीक्षण किया। कृपया अपने डाउनवोट को वापस लें।
होबोड्वे

@ ओहो, सिर्फ इसलिए कि तुम्हारे अधिकार का मतलब यह नहीं है कि उसे यह पसंद है।
क्रिस एस

क्रिस, क्या आप बता सकते हैं कि वह कैसे सही है? पहला लेनदेन हल करने के लिए कोई संदेश COMMITया ROLLBACKसंदेश नहीं भेजा जाता है तो दूसरा लेनदेन कैसे होगा ? होबोव्वे, शायद यह उपयोगी होगा यदि आपने अपना परीक्षण कोड प्रस्तुत किया।
ट्रेवर बर्नहैम

2
@ ट्रेवर: आप समझदारी नहीं बना रहे हैं। आप लेनदेन को क्रमबद्ध करना चाहते हैं, है ना? हां, आपने अपने अन्य प्रश्न में ऐसा कहा है और इस प्रश्न में यहां दोहराएं। यदि पहला लेन-देन पूरा नहीं हुआ है, तो पृथ्वी पर आप दूसरे लेनदेन के पूरा होने की उम्मीद कैसे करेंगे? आपने स्पष्ट रूप से यह बताया है कि उस पंक्ति के लॉक होने की प्रतीक्षा करें। इसलिए इंतजार करना होगा। आप इस बारे में क्या नहीं समझते हैं?
होबोडेव

1

इसी तरह की स्थिति में मेरी टीम ने pt-किल ( https://www.percona.com/doc/percona-toolkit/2.1/pt-kill.html ) का उपयोग करने का निर्णय लिया । यह उन प्रश्नों पर रिपोर्ट कर सकता है या मार सकता है जो (अन्य चीजों के बीच) बहुत लंबे समय से चल रहे हैं। फिर इसे हर एक्स मिनट में क्रोन में चलाना संभव है।

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

प्रारंभिक क्वेरी को ठीक करने के लिए निश्चित रूप से तय किया गया था, लेकिन भविष्य में गलती से होने वाली स्थिति से बचने के लिए, यह बहुत अच्छा होगा यदि यह विशिष्ट समय से अधिक समय तक चलने वाले लेनदेन / प्रश्नों को ऑटो-किल (या रिपोर्ट) करना संभव था, प्रश्न के कौन से लेखक पूछ रहे हैं। यह pt-किल के साथ उल्लेखनीय है।


0

एक सरल समाधान यह होगा कि आपके आवश्यक timeoutसमय से अधिक समय लेने वाले प्रश्नों को मारने के लिए और innodb_rollback_on_timeoutइसके साथ विकल्प का उपयोग करने के लिए एक संग्रहीत प्रक्रिया हो।


-2

थोड़ी देर के लिए चारों ओर घूमने के बाद, ऐसा लगता है कि प्रति लेनदेन समय सीमा निर्धारित करने का कोई सीधा तरीका नहीं है। यहाँ सबसे अच्छा समाधान है जो मैं पा रहा था:

आदेश

SHOW PROCESSLIST;

आपको वर्तमान में चलाए जा रहे सभी आदेशों के साथ एक तालिका देता है और समय (सेकंड में) जब से उन्होंने शुरू किया। जब एक क्लाइंट ने कमांड देना बंद कर दिया है, तो उन्हें एक Sleepकमांड देने के रूप में वर्णित किया जाता है , जिसमें Timeकॉलम अंतिम सेकंड की संख्या होने के बाद भी पूरा होता है। तो आप मैन्युअल रूप से अंदर जा सकते हैं और KILLसब कुछ है कि एक Timeमूल्य से अधिक है, कहते हैं, 5 सेकंड अगर आप आश्वस्त हैं कि आपके डेटाबेस से कोई क्वेरी 5 सेकंड से अधिक नहीं होनी चाहिए। उदाहरण के लिए, यदि id 3 वाली प्रक्रिया के Timeकॉलम में 12 का मान है , तो आप कर सकते हैं

KILL 3;

KIL सिंटैक्स के लिए प्रलेखन से पता चलता है कि उस आईडी के साथ थ्रेड द्वारा किया जा रहा एक लेन-देन वापस रोल किया जाएगा (हालांकि मैंने यह परीक्षण नहीं किया है, इसलिए सतर्क रहें)।

लेकिन इसे कैसे स्वचालित करें और हर 5 सेकंड में सभी ओवरटाइम स्क्रिप्ट को मारें? उसी पृष्ठ पर पहली टिप्पणी हमें एक संकेत देती है, लेकिन कोड PHP में है; ऐसा लगता है कि हम एक ऐसा नहीं कर सकते SELECTपर SHOW PROCESSLISTMySQL ग्राहक के भीतर से। फिर भी, यह मानते हुए कि हमारे पास एक PHP डेमॉन है जिसे हम हर $MAX_TIMEसेकंड चलाते हैं , यह कुछ इस तरह दिख सकता है:

$result = mysql_query("SHOW FULL PROCESSLIST");
while ($row=mysql_fetch_array($result)) {
  $process_id=$row["Id"];
    if ($row["Time"] > $MAX_TIME) {
      $sql="KILL $process_id";
      mysql_query($sql);
  }
}

ध्यान दें कि यह सभी निष्क्रिय ग्राहक कनेक्शन को फिर से जोड़ने के लिए मजबूर करने का दुष्प्रभाव होगा , न कि केवल उन लोगों के साथ जो दुर्व्यवहार कर रहे हैं।

यदि किसी के पास बेहतर उत्तर है, तो मुझे यह सुनना अच्छा लगेगा।

संपादित करें:KILL इस तरह से उपयोग करने का कम से कम एक गंभीर जोखिम है । मान लीजिए कि आप KILL10 सेकंड के लिए निष्क्रिय हर कनेक्शन के लिए उपरोक्त स्क्रिप्ट का उपयोग करते हैं । एक कनेक्शन के बाद 10 सेकंड के लिए निष्क्रिय कर दिया गया है, लेकिन KILLजारी होने से पहले , जिस उपयोगकर्ता का कनेक्शन मारा जा रहा है वह एक START TRANSACTIONकमांड जारी करता है। वे फिर KILLएड। वे एक UPDATEऔर फिर दो बार सोचते हैं, एक जारी करते हैं ROLLBACK। हालाँकि, क्योंकि KILLउनके मूल लेन-देन को वापस ले लिया गया था, इसलिए अपडेट तुरंत ही हो गया और उसे वापस नहीं लाया जा सका! परीक्षण के मामले के लिए यह पोस्ट देखें ।


2
यह टिप्पणी इस उत्तर के भविष्य के पाठकों के लिए है। कृपया ऐसा न करें, भले ही वह स्वीकृत उत्तर हो।
होबोड्वे

ठीक है, एक नकारात्मक टिप्पणी छोड़ने और छोड़ने के बजाय, यह समझाने के बारे में कि यह एक बुरा विचार क्यों होगा? मूल PHP स्क्रिप्ट पोस्ट करने वाले व्यक्ति ने कहा कि इसने अपने सर्वर को लटकाए रखा; अगर एक ही लक्ष्य हासिल करने का बेहतर तरीका है, तो मुझे दिखाओ।
ट्रेवर बर्नहैम

6
टिप्पणी नहीं है। यह भविष्य के सभी पाठकों के लिए आपके "समाधान" का उपयोग करने पर कोई प्रयास नहीं करने की चेतावनी है। स्वचालित रूप से लंबे समय तक चलने वाले लेनदेन को मारना एक एकतरफा भयानक विचार है। इसे कभी नहीं करना चाहिए । यही स्पष्टीकरण है। हत्या सत्र अपवाद नहीं होना चाहिए, अपवाद होना चाहिए। मूल कारण अपने काल्पनिक समस्या के उपयोगकर्ता त्रुटि है। आप डीबीए के लिए तकनीकी समाधान नहीं बनाते हैं जो पंक्तियों को लॉक करते हैं और फिर "दूर चलते हैं"। आप उन्हें अग्नि दें।
hobodave

-2

जैसा कि एक टिप्पणी में सुझाव दिया गया है, कुछ mysqlलेन-देन की समय सीमा निर्धारित करने के लिए कुछ क्लाइंट्स में (हालांकि, जाहिरा तौर पर, कमांड-लाइन उपयोगिता) संभव है। यहां रूबी में ActiveRecord का उपयोग करके प्रदर्शन किया गया है:

require 'rubygems'
require 'timeout'
require 'active_record'

Timeout::timeout(5) {
  Foo.transaction do
    Foo.create(:name => 'Bar')
    sleep 10
  end
}

इस उदाहरण में, लेनदेन 5 सेकंड के बाद बाहर हो जाता है और स्वचालित रूप से वापस आ जाता है । ( हॉबोडेव की टिप्पणी के जवाब में अपडेट करें: यदि डेटाबेस को प्रतिक्रिया देने में 5 सेकंड से अधिक समय लगता है, तो लेन-देन को जल्द से जल्द वापस ले लिया जाएगा - जल्द ही नहीं।) यदि आप यह सुनिश्चित करना चाहते हैं कि आपके सभी लेनदेन nसेकंड के बाद बाहर हो जाएं । आप ActiveRecord के आसपास एक आवरण बना सकते हैं। मैं अनुमान लगा रहा हूं कि यह जावा, .NET, पायथन, आदि में सबसे लोकप्रिय पुस्तकालयों पर भी लागू होता है, लेकिन मैंने अभी तक इनका परीक्षण नहीं किया है। (यदि आपके पास है, तो कृपया इस उत्तर पर एक टिप्पणी पोस्ट करें।)

ActiveRecord में लेन-देन भी सुरक्षित होने का लाभ है यदि KILLजारी किया जाता है, कमांड लाइन से किए गए लेनदेन के विपरीत। Https://dba.stackexchange.com/questions/1561/mysql-client-believes-theyre-in-a-transaction-gets-killed-wreaks-havoc देखें ।

सर्वर पर अधिकतम लेन-देन के समय को लागू करना संभव नहीं प्रतीत होता है, सिवाय एक स्क्रिप्ट के जैसे कि मैंने अपने दूसरे उत्तर में पोस्ट किया था।


आपने यह अनदेखी की है कि ActiveRecord सिंक्रोनस (ब्लॉकिंग) I / O का उपयोग करता है। वह सब स्क्रिप्ट जो कर रही है वह रूबी नींद कमांड को बाधित कर रही है। यदि आपकी Foo.createकमांड 5 मिनट के लिए अवरुद्ध हो जाती है, तो टाइमआउट इसे नहीं मारेगा। यह आपके प्रश्न में दिए गए उदाहरण से असंगत है। A SELECT ... FOR UPDATEआसानी से किसी भी अन्य प्रश्न के रूप में लंबे समय के लिए ब्लॉक कर सकता है।
होबोड्वे

यह ध्यान दिया जाना चाहिए कि लगभग सभी mysql ग्राहक पुस्तकालय I / O को अवरुद्ध करने का उपयोग करते हैं, इसलिए मेरे जवाब में सुझाव है कि आपको अपने स्वयं के उपयोग या लिखने की आवश्यकता होगी जो गैर-अवरुद्ध I / O का उपयोग करते थे। : यहाँ समय समाप्त बेकार होने का एक सरल प्रदर्शन है gist.github.com/856100
hobodave

मैं वास्तव में एक परिदृश्य के साथ अपने प्रश्न में अधिक चिंतित था जिसमें ग्राहक ऐप हैंग (एक अनंत लूप में फंस जाता है) एक लेनदेन की अवधि के दौरान एक से अधिक होता है जिसमें लेनदेन MySQL के अंत में एक लंबा समय लगता है। लेकिन धन्यवाद, यह एक अच्छी बात है। मैंने इसे नोट करने के लिए सवाल अपडेट किया है।)
ट्रेवर बर्नहैम

मैं आपके दावे के परिणामों की नकल नहीं कर सकता। मैंने उपयोग करने के लिए जिस्ट को अद्यतन किया ActiveRecord::Base#find_by_sql: gist.github.com/856100 फिर, यह इसलिए है क्योंकि AR I / O को अवरुद्ध करने का उपयोग करता है।
होबोडवे

@ ओहोबोडे हां, यह संपादन गलत था और इसे ठीक कर लिया गया है। स्पष्ट होने के लिए: timeoutविधि लेन-देन को वापस कर देगी, लेकिन तब तक नहीं जब तक MySQL डेटाबेस किसी प्रश्न का उत्तर नहीं देता। तो timeoutविधि ग्राहक पक्ष या लंबे लेनदेन को रोकने के लिए उपयुक्त है जिसमें कई अपेक्षाकृत छोटे प्रश्न शामिल हैं, लेकिन लंबे लेनदेन के लिए नहीं जिसमें एक ही क्वेरी अपराधी है।
ट्रेवर बर्नहैम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.