106

EN + हिं Easy

GB What is the timeout-based deadlock handling approach and what are its trade-offs?

IN टाइमआउट-आधारित गतिरोध प्रबंधन दृष्टिकोण क्या है और इसके ट्रेड-ऑफ़ क्या हैं?

A

Automatically increasing lock timeout when near deadlock गतिरोध के निकट होने पर स्वचालित रूप से लॉक टाइमआउट बढ़ाना

B

Aborting a transaction if it has been waiting for a lock longer than a specified timeout period assuming it may be deadlocked; trade-offs: simple to implement no detection overhead but may abort non-deadlocked transactions (false positives) and may take long to detect actual deadlocks यदि कोई लेन-देन एक निर्दिष्ट समय-सीमा से अधिक समय तक लॉक की प्रतीक्षा कर रहा है, तो यह मानते हुए कि यह गतिरोध हो सकता है, रद्द करना; ट्रेड-ऑफ़: ओवरहेड का पता लगाने के बिना लागू करना आसान है, लेकिन गैर-गतिरोधित लेनदेन (झूठी सकारात्मक) को रद्द कर सकता है और वास्तविक गतिरोधों का पता लगाने में लंबा समय लग सकता है

C

Using a timer to order lock acquisitions लॉक अधिग्रहण का ऑर्डर देने के लिए टाइमर का उपयोग करना

D

Killing transactions that take more than 1 second 1 सेकंड से अधिक समय लेने वाले लेनदेन को समाप्त करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Timeout approach: LOCK_WAIT_TIMEOUT=50 (seconds). If waiting > 50s, abort. Trade-offs: Too short - false aborts (slow queries killed). Too long - deadlocks detected late. Simple but imprecise. Most systems use timeout as fallback with real detection as primary mechanism.

व्याख्या (हिन्दी) टाइमआउट दृष्टिकोण: LOCK_WAIT_TIMEOUT=50 (सेकंड)। यदि प्रतीक्षा 50 से अधिक है, तो गर्भपात करें। ट्रेड-ऑफ़: बहुत छोटा - झूठा गर्भपात (धीमी क्वेरी ख़त्म)। बहुत लंबा - गतिरोध का देर से पता चला। सरल लेकिन अचूक. अधिकांश सिस्टम प्राथमिक तंत्र के रूप में वास्तविक पहचान के साथ फ़ॉलबैक के रूप में टाइमआउट का उपयोग करते हैं।

107

EN + हिं Easy

GB What is edge chasing for distributed deadlock detection?

IN वितरित गतिरोध का पता लगाने के लिए एज चेज़िंग क्या है?

A

A graph traversal for query optimization क्वेरी अनुकूलन के लिए एक ग्राफ़ ट्रैवर्सल

B

An algorithm for detecting missing indexes लापता अनुक्रमणिका का पता लगाने के लिए एक एल्गोरिदम

C

Nodes proactively push probe messages along wait-for edges toward the transaction being waited for; if a probe returns to its origin a cycle (deadlock) is detected; avoids the need for a centralized global wait-for graph नोड्स सक्रिय रूप से जांच संदेशों को प्रतीक्षा-किनारों के साथ-साथ प्रतीक्षा किए जा रहे लेनदेन की ओर धकेलते हैं; यदि कोई जांच अपने मूल स्थान पर लौटती है तो एक चक्र (गतिरोध) का पता चलता है; एक केंद्रीकृत वैश्विक प्रतीक्षा-ग्राफ़ की आवश्यकता से बचा जाता है

D

Traversing index B-tree edges इंडेक्स बी-ट्री किनारों को ट्रैवर्स करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Edge chasing: T1 waits for T2 (node A waits for node B). A sends probe to B. B sees T2 waits for T3 (node C). B forwards probe to C. If probe reaches T1 again: T1 to T2 to T3 to T1 cycle detected. C notifies T1 to abort. Fully distributed, no central coordinator needed.

व्याख्या (हिन्दी) किनारे का पीछा करना: T1 T2 की प्रतीक्षा करता है (नोड A नोड B की प्रतीक्षा करता है)। A, B को जांच भेजता है। B देखता है कि T2, T3 (नोड C) की प्रतीक्षा कर रहा है। B जांच को C की ओर अग्रेषित करता है। यदि जांच फिर से T1 तक पहुंचती है: T1 से T2 से T3 से T1 चक्र का पता लगाया जाता है। C, T1 को गर्भपात के लिए सूचित करता है। पूरी तरह से वितरित, किसी केंद्रीय समन्वयक की आवश्यकता नहीं।

108

EN + हिं Hard

GB What is deadlock avoidance vs deadlock prevention and which requires advance knowledge?

IN गतिरोध परिहार बनाम गतिरोध निवारण क्या है और जिसके लिए अग्रिम ज्ञान की आवश्यकता है?

A

Deadlock prevention requires advance knowledge; avoidance does not गतिरोध की रोकथाम के लिए अग्रिम ज्ञान की आवश्यकता होती है; परहेज नहीं है

B

They are identical strategies वे समान रणनीतियाँ हैं

C

Deadlock prevention eliminates one of the Coffman conditions (no advance knowledge needed). Deadlock avoidance requires each transaction to declare maximum resource needs in advance; the system uses this to determine if granting a request could lead to deadlock and denies unsafe requests गतिरोध की रोकथाम कॉफ़मैन स्थितियों में से एक को समाप्त कर देती है (कोई अग्रिम ज्ञान की आवश्यकता नहीं है)। गतिरोध से बचने के लिए प्रत्येक लेनदेन के लिए अधिकतम संसाधन आवश्यकताओं की पहले से घोषणा करना आवश्यक है; सिस्टम इसका उपयोग यह निर्धारित करने के लिए करता है कि क्या अनुरोध देने से गतिरोध पैदा हो सकता है और असुरक्षित अनुरोधों को अस्वीकार कर देता है

D

Deadlock avoidance requires no advance knowledge गतिरोध से बचने के लिए किसी अग्रिम ज्ञान की आवश्यकता नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Prevention: eliminate condition (e.g., lock ordering) - no advance knowledge needed, always enforced. Avoidance: allow dynamic lock acquisition but use advance knowledge (maximum needs declared) to avoid unsafe states. Bankers algorithm: grant request only if resulting state is safe. Avoidance is more concurrent than prevention.

व्याख्या (हिन्दी) रोकथाम: स्थिति को समाप्त करें (उदाहरण के लिए, लॉक ऑर्डरिंग) - किसी अग्रिम ज्ञान की आवश्यकता नहीं है, हमेशा लागू किया जाता है। बचाव: गतिशील लॉक अधिग्रहण की अनुमति दें लेकिन असुरक्षित स्थितियों से बचने के लिए अग्रिम ज्ञान (घोषित अधिकतम आवश्यकताएं) का उपयोग करें। बैंकर्स एल्गोरिदम: अनुरोध तभी स्वीकार करें जब परिणामी स्थिति सुरक्षित हो। रोकथाम की तुलना में बचाव अधिक समवर्ती है।

109

EN + हिं Easy

GB What is the deadlock frequency trade-off in choosing lock granularity?

IN लॉक ग्रैन्युलैरिटी चुनने में गतिरोध आवृत्ति ट्रेड-ऑफ़ क्या है?

A

Coarser granularity (table locks): fewer locks per transaction = fewer potential conflicts = fewer deadlocks but less concurrency. Finer granularity (row locks): more locks per transaction = more potential for circular wait = higher deadlock probability but higher concurrency मोटे ग्रैन्युलैरिटी (टेबल लॉक): प्रति लेनदेन कम लॉक = कम संभावित टकराव = कम गतिरोध लेकिन कम समवर्तीता। बेहतर ग्रैन्युलैरिटी (पंक्ति लॉक): प्रति लेनदेन अधिक लॉक = सर्कुलर प्रतीक्षा के लिए अधिक क्षमता = उच्च गतिरोध संभावना लेकिन उच्च संगामिति

B

Finer granularity always reduces deadlocks बेहतर ग्रैन्युलैरिटी हमेशा गतिरोध को कम करती है

C

Finer granularity always increases deadlocks बारीक विवरण हमेशा गतिरोध बढ़ाता है

D

Lock granularity does not affect deadlock frequency लॉक ग्रैन्युलैरिटी डेडलॉक आवृत्ति को प्रभावित नहीं करती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Trade-off: row-level locking: maximum concurrency, but T1 holds row 1 wants row 2, T2 holds row 2 wants row 1 = deadlock. Table-level locking: only one transaction at a time per table = no row-level deadlocks but low concurrency. Most OLTP uses row-level locks with deadlock detection as practical balance.

व्याख्या (हिन्दी) ट्रेड-ऑफ़: पंक्ति-स्तरीय लॉकिंग: अधिकतम संगामिति, लेकिन T1 पंक्ति 1 को रखता है, पंक्ति 2 चाहता है, T2 पंक्ति 2 को रखता है, पंक्ति 1 चाहता है = गतिरोध। तालिका-स्तरीय लॉकिंग: प्रति तालिका एक समय में केवल एक लेनदेन = कोई पंक्ति-स्तरीय गतिरोध नहीं बल्कि कम संगामिति। अधिकांश ओएलटीपी व्यावहारिक संतुलन के रूप में गतिरोध का पता लगाने के साथ पंक्ति-स्तरीय ताले का उपयोग करते हैं।

110

EN + हिं Medium

GB How can application developers minimize the probability of deadlocks?

IN एप्लिकेशन डेवलपर गतिरोध की संभावना को कैसे कम कर सकते हैं?

A

By using READ UNCOMMITTED isolation level always रीड अनकमिटेड आइसोलेशन लेवल का हमेशा उपयोग करके

B

By avoiding all concurrent transactions सभी समवर्ती लेन-देन से बचकर

C

Best practices: (1) Acquire locks in consistent order across all transactions. (2) Keep transactions short (fewer locks held for less time). (3) Access data in same order. (4) Use appropriate isolation level. (5) Use SELECT FOR UPDATE to acquire all needed locks upfront. (6) Retry logic for deadlock errors सर्वोत्तम प्रथाएँ: (1) सभी लेन-देन में सुसंगत क्रम में ताले प्राप्त करें। (2) लेन-देन छोटा रखें (कम समय के लिए कम ताले रखें)। (3) डेटा को उसी क्रम में एक्सेस करें। (4) उचित अलगाव स्तर का उपयोग करें। (5) सभी आवश्यक ताले अग्रिम रूप से प्राप्त करने के लिए सेलेक्ट फॉर अपडेट का उपयोग करें। (6) गतिरोध त्रुटियों के लिए तर्क पुनः प्रयास करें

D

By using only table-level locks केवल टेबल-स्तरीय ताले का उपयोग करके

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Deadlock minimization: (1) Consistent ordering: all code paths access tables/rows in same order. (2) Short transactions: commit ASAP, release locks. (3) Avoid user interaction within transactions. (4) Fetch all needed rows in one query. (5) Batch operations. (6) Application retry on deadlock error (1213 MySQL, SQLState 40P01 PostgreSQL).

व्याख्या (हिन्दी) गतिरोध न्यूनतमकरण: (1) सुसंगत क्रम: सभी कोड पथ एक ही क्रम में तालिकाओं/पंक्तियों तक पहुंचते हैं। (2) लघु लेनदेन: यथाशीघ्र प्रतिबद्ध हों, ताले जारी करें। (3) लेन-देन के भीतर उपयोगकर्ता के संपर्क से बचें। (4) सभी आवश्यक पंक्तियों को एक क्वेरी में प्राप्त करें। (5) बैच संचालन। (6) डेडलॉक त्रुटि (1213 MySQL, SQLState 40P01 PostgreSQL) पर एप्लिकेशन पुनः प्रयास करें।

111

EN + हिं Easy

GB What is the relationship between deadlocks and the two-phase locking protocol?

IN गतिरोध और दो-चरण लॉकिंग प्रोटोकॉल के बीच क्या संबंध है?

A

2PL prevents all deadlocks 2PL सभी गतिरोधों को रोकता है

B

2PL guarantees serializability but does NOT prevent deadlocks; in fact 2PL can cause deadlocks because transactions hold locks during the shrinking phase while waiting for new locks - deadlock prevention or detection must be combined with 2PL separately 2PL क्रमबद्धता की गारंटी देता है लेकिन गतिरोध को नहीं रोकता है; वास्तव में 2PL गतिरोध का कारण बन सकता है क्योंकि नए तालों की प्रतीक्षा करते समय सिकुड़न चरण के दौरान लेन-देन में ताले लगे रहते हैं - गतिरोध की रोकथाम या पता लगाने को 2PL के साथ अलग से जोड़ा जाना चाहिए

C

2PL detects deadlocks automatically 2PL स्वचालित रूप से गतिरोध का पता लगाता है

D

Deadlocks are impossible with 2PL 2PL के साथ गतिरोध असंभव है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) 2PL and deadlocks: 2PL ensures the lock point creates a serial order but does not prevent circular wait. T1 (2PL): holds A, requests B. T2 (2PL): holds B, requests A. Both in growing phase, neither can release. Classic deadlock under 2PL. 2PL must be combined with deadlock detection or prevention separately.

व्याख्या (हिन्दी) 2PL और गतिरोध: 2PL सुनिश्चित करता है कि लॉक पॉइंट एक सीरियल ऑर्डर बनाता है लेकिन सर्कुलर प्रतीक्षा को नहीं रोकता है। T1 (2PL): A को होल्ड करता है, B को अनुरोध करता है। T2 (2PL): B को होल्ड करता है, A को अनुरोध करता है। दोनों बढ़ते चरण में हैं, कोई भी रिलीज़ नहीं कर सकता है। 2PL के अंतर्गत क्लासिक गतिरोध। 2PL को गतिरोध का पता लगाने या रोकथाम के साथ अलग से जोड़ा जाना चाहिए।

112

EN + हिं Medium

GB What is a deadlock graph visualization and how does it help in diagnosing production deadlock issues?

IN डेडलॉक ग्राफ़ विज़ुअलाइज़ेशन क्या है और यह उत्पादन गतिरोध समस्याओं के निदान में कैसे मदद करता है?

A

A graph showing query execution times क्वेरी निष्पादन समय दर्शाने वाला ग्राफ़

B

A graph showing database query costs डेटाबेस क्वेरी लागत दर्शाने वाला ग्राफ़

C

A graph of database connection patterns डेटाबेस कनेक्शन पैटर्न का एक ग्राफ़

D

A visual representation of transactions as nodes and lock wait relationships as directed edges; cycles indicate deadlocks; helps identify: which transactions are involved which specific rows/tables are the contention points what SQL statements caused conflicts and patterns suggesting application-level fixes नोड्स के रूप में लेनदेन का एक दृश्य प्रतिनिधित्व और निर्देशित किनारों के रूप में लॉक प्रतीक्षा संबंध; चक्र गतिरोध का संकेत देते हैं; पहचानने में मदद करता है: कौन से लेन-देन शामिल हैं, कौन सी विशिष्ट पंक्तियाँ/तालियाँ विवाद बिंदु हैं, कौन से SQL कथनों के कारण टकराव हुआ और एप्लिकेशन-स्तरीय सुधारों का सुझाव देने वाले पैटर्न

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Deadlock graph analysis: SHOW ENGINE INNODB STATUS output shows transactions and their lock waits. Tools like pt-deadlock-logger, Percona Monitoring parse deadlock info. Pattern analysis: if same two tables always appear, fix transaction ordering. If same rows: add index to reduce scan scope (fewer row locks held simultaneously).

व्याख्या (हिन्दी) डेडलॉक ग्राफ विश्लेषण: शो इंजन इननोब स्टेटस आउटपुट लेनदेन और उनके लॉक प्रतीक्षा को दिखाता है। पीटी-डेडलॉक-लॉगर, पेरकोना मॉनिटरिंग पार्स डेडलॉक जानकारी जैसे उपकरण। पैटर्न विश्लेषण: यदि समान दो तालिकाएँ हमेशा दिखाई देती हैं, तो लेनदेन क्रम ठीक करें। यदि पंक्तियाँ समान हों: स्कैन का दायरा कम करने के लिए अनुक्रमणिका जोड़ें (एक साथ कम पंक्ति लॉक रखें)।

113

EN + हिं Medium

GB In MySQL InnoDB when a deadlock is detected what information does InnoDB provide?

IN MySQL InnoDB में जब गतिरोध का पता चलता है तो InnoDB क्या जानकारी प्रदान करता है?

A

InnoDB does not detect deadlocks automatically InnoDB स्वचालित रूप से गतिरोध का पता नहीं लगाता है

B

InnoDB prevents all deadlocks using lock ordering InnoDB लॉक ऑर्डरिंग का उपयोग करके सभी गतिरोधों को रोकता है

C

MySQL requires manual deadlock detection by the application MySQL को एप्लिकेशन द्वारा मैन्युअल गतिरोध का पता लगाने की आवश्यकता होती है

D

InnoDB has automatic deadlock detection using a wait-for graph; when detected the transaction with less undo log is chosen as victim and rolled back; deadlock information is accessible via SHOW ENGINE INNODB STATUS or the performance_schema.data_lock_waits table InnoDB में प्रतीक्षा-ग्राफ़ का उपयोग करके स्वचालित गतिरोध का पता लगाना है; जब कम पूर्ववत लॉग वाले लेन-देन का पता चलता है तो उसे पीड़ित के रूप में चुना जाता है और वापस ले लिया जाता है; गतिरोध की जानकारी SHOW ENGINE INNODB STATUS या Performance_schema.data_lock_waits तालिका के माध्यम से पहुंच योग्य है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) InnoDB deadlock detection: background thread monitors wait-for graph. Victim: transaction with smallest undo log size rolled back. SHOW ENGINE INNODB STATUS: shows LATEST DETECTED DEADLOCK section with transaction details, lock information, and the SQL statements involved. innodb_deadlock_detect=OFF disables detection.

व्याख्या (हिन्दी) InnoDB गतिरोध का पता लगाना: पृष्ठभूमि थ्रेड प्रतीक्षा-ग्राफ़ की निगरानी करता है। पीड़ित: सबसे छोटे पूर्ववत लॉग आकार वाला लेन-देन वापस ले लिया गया। इंजन इननोड स्थिति दिखाएं: लेन-देन विवरण, लॉक जानकारी और शामिल एसक्यूएल स्टेटमेंट के साथ नवीनतम पता लगाया गया डेडलॉक अनुभाग दिखाता है। innodb_deadlock_detect=OFF पता लगाना अक्षम कर देता है।

114

EN + हिं Easy

GB What is mutual exclusion as a Coffman condition and can it be eliminated in database systems to prevent deadlocks?

IN कॉफ़मैन स्थिति के रूप में पारस्परिक बहिष्करण क्या है और क्या गतिरोध को रोकने के लिए डेटाबेस सिस्टम में इसे समाप्त किया जा सकता है?

A

Mutual exclusion can always be eliminated पारस्परिक बहिष्कार को हमेशा समाप्त किया जा सकता है

B

Mutual exclusion means resources (data items) can only be held by one transaction at a time in write mode; for READ locks mutual exclusion can be eliminated (multiple readers allowed) via shared locks reducing deadlock probability; but write locks inherently require mutual exclusion for correctness पारस्परिक बहिष्करण का मतलब है कि संसाधनों (डेटा आइटम) को एक समय में केवल एक लेनदेन द्वारा लेखन मोड में रखा जा सकता है; रीड लॉक के लिए आपसी बहिष्करण को साझा लॉक के माध्यम से समाप्त किया जा सकता है (एकाधिक पाठकों को अनुमति दी गई है) जिससे गतिरोध की संभावना कम हो जाती है; लेकिन राइट लॉक को शुद्धता के लिए स्वाभाविक रूप से पारस्परिक बहिष्कार की आवश्यकता होती है

C

Mutual exclusion elimination removes all deadlocks पारस्परिक बहिष्कार उन्मूलन से सभी गतिरोध दूर हो जाते हैं

D

Databases do not use the mutual exclusion concept डेटाबेस पारस्परिक बहिष्करण अवधारणा का उपयोग नहीं करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Eliminating mutual exclusion for reads: shared/read locks allow multiple concurrent readers. This reduces deadlocks significantly. Write mutual exclusion: cannot be eliminated while maintaining data integrity (two concurrent writes to same data = incorrect result). MVCC eliminates read-write mutual exclusion by using versioning.

व्याख्या (हिन्दी) पढ़ने के लिए पारस्परिक बहिष्करण को समाप्त करना: साझा/पढ़ने वाले लॉक एकाधिक समवर्ती पाठकों की अनुमति देते हैं। इससे गतिरोध काफी हद तक कम हो जाता है। पारस्परिक बहिष्करण लिखें: डेटा अखंडता को बनाए रखते हुए समाप्त नहीं किया जा सकता है (एक ही डेटा पर दो समवर्ती लेखन = गलत परिणाम)। एमवीसीसी वर्जनिंग का उपयोग करके पढ़ने-लिखने के पारस्परिक बहिष्करण को समाप्त करता है।

115

EN + हिं Medium

GB What is the application-level deadlock and how does it differ from database-level deadlock?

IN एप्लिकेशन-स्तरीय गतिरोध क्या है और यह डेटाबेस-स्तरीय गतिरोध से कैसे भिन्न है?

A

They are identical types of deadlocks वे समान प्रकार के गतिरोध हैं

B

Application-level deadlocks are faster to resolve एप्लिकेशन-स्तरीय गतिरोधों का समाधान तेजी से होता है

C

Application deadlocks cannot occur with a DBMS DBMS के साथ एप्लिकेशन गतिरोध उत्पन्न नहीं हो सकता

D

Application-level deadlock: occurs in application code (e.g. Thread A holds Java lock L1 waiting for Java lock L2; Thread B holds L2 waiting for L1) without involving database locks - the database itself is not deadlocked but the application threads are stuck. Different from DB deadlock where DBMS transactions hold DB locks circularly एप्लिकेशन-स्तरीय गतिरोध: एप्लिकेशन कोड में होता है (उदाहरण के लिए थ्रेड ए जावा लॉक एल1 को जावा लॉक एल2 के इंतजार में रखता है; थ्रेड बी एल2 को एल1 के इंतजार में रखता है) डेटाबेस लॉक को शामिल किए बिना - डेटाबेस स्वयं डेडलॉक नहीं है लेकिन एप्लिकेशन थ्रेड अटके हुए हैं। डीबी गतिरोध से भिन्न जहां डीबीएमएस लेनदेन डीबी लॉक को गोलाकार रूप से रखता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Application deadlock: circular waiting in application code (mutexes, semaphores, Java synchronized blocks). DBMS cannot detect this. Solution: application must implement its own deadlock detection or prevention (consistent lock ordering in application code, timeouts in application logic). Different from DBMS-level deadlocks that the DB detects/resolves.

व्याख्या (हिन्दी) एप्लिकेशन गतिरोध: एप्लिकेशन कोड में सर्कुलर प्रतीक्षा (म्यूटेक्स, सेमाफोर, जावा सिंक्रोनाइज्ड ब्लॉक)। DBMS इसका पता नहीं लगा सकता. समाधान: एप्लिकेशन को अपने स्वयं के गतिरोध का पता लगाने या रोकथाम (एप्लिकेशन कोड में लगातार लॉक ऑर्डर, एप्लिकेशन लॉजिक में टाइमआउट) को लागू करना होगा। DBMS-स्तर के गतिरोधों से भिन्न जिनका DB पता लगाता/समाधान करता है।

116

EN + हिं Easy

GB What is the Bankers algorithm for deadlock avoidance and what information does it require?

IN गतिरोध से बचने के लिए बैंकर्स एल्गोरिदम क्या है और इसके लिए किस जानकारी की आवश्यकता है?

A

A resource allocation algorithm that determines whether granting a resource request leaves the system in a safe state; requires: for each transaction - maximum resource needs declared in advance current allocation and remaining need; safe state = exists a sequence in which all transactions can complete using available resources एक संसाधन आवंटन एल्गोरिदम जो यह निर्धारित करता है कि संसाधन अनुरोध देने से सिस्टम सुरक्षित स्थिति में रहता है या नहीं; आवश्यक है: प्रत्येक लेनदेन के लिए - अधिकतम संसाधन आवश्यकताओं की घोषणा अग्रिम वर्तमान आवंटन और शेष आवश्यकता; सुरक्षित स्थिति = एक अनुक्रम मौजूद है जिसमें सभी लेनदेन उपलब्ध संसाधनों का उपयोग करके पूरा किया जा सकता है

B

An algorithm for distributing resources evenly among transactions लेन-देन के बीच संसाधनों को समान रूप से वितरित करने के लिए एक एल्गोरिदम

C

A financial transaction scheduling algorithm एक वित्तीय लेनदेन शेड्यूलिंग एल्गोरिदम

D

A banking application algorithm for managing transactions लेनदेन के प्रबंधन के लिए एक बैंकिंग एप्लिकेशन एल्गोरिदम

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Bankers algorithm: Safe state check before each allocation. Data needed: Available (resources currently free), Max (maximum needs per transaction), Allocation (current allocation), Need (Max - Allocation). Safety check: find a transaction whose Need <= Available, simulate completion (release allocation), repeat. If all transactions can complete: safe state, grant. Else: deny and wait.

व्याख्या (हिन्दी) बैंकर्स एल्गोरिदम: प्रत्येक आवंटन से पहले सुरक्षित स्थिति की जांच। आवश्यक डेटा: उपलब्ध (संसाधन वर्तमान में निःशुल्क), अधिकतम (प्रति लेनदेन अधिकतम आवश्यकताएं), आवंटन (वर्तमान आवंटन), आवश्यकता (अधिकतम - आवंटन)। सुरक्षा जांच: ऐसा लेन-देन ढूंढें जिसकी आवश्यकता है

117

EN + हिं Easy

GB What is the hold-and-wait Coffman condition and what strategies eliminate it in database systems?

IN होल्ड-एंड-वेट कॉफ़मैन स्थिति क्या है और कौन सी रणनीतियाँ डेटाबेस सिस्टम में इसे समाप्त करती हैं?

A

Hold-and-wait: a transaction holds one or more resources (locks) while waiting to acquire additional resources it needs. Elimination strategies: (1) Require all-or-nothing lock acquisition (acquire ALL needed locks at once before starting) (2) Release all current locks before requesting new ones (3) Use timeout-based retry after releasing होल्ड-एंड-वेट: एक लेनदेन आवश्यक अतिरिक्त संसाधनों को प्राप्त करने की प्रतीक्षा करते समय एक या अधिक संसाधनों (लॉक) को रखता है। उन्मूलन रणनीतियाँ: (1) सभी या कुछ भी नहीं लॉक अधिग्रहण की आवश्यकता है (शुरू करने से पहले सभी आवश्यक लॉक एक साथ प्राप्त करें) (2) नए लॉक का अनुरोध करने से पहले सभी मौजूदा लॉक जारी करें (3) जारी करने के बाद टाइमआउट-आधारित पुनः प्रयास का उपयोग करें

B

A performance optimization for lock management लॉक प्रबंधन के लिए एक प्रदर्शन अनुकूलन

C

Holding locks for too long during transactions लेन-देन के दौरान बहुत देर तक ताले लटकाए रखना

D

A condition where all resources are held by one transaction ऐसी स्थिति जहां सभी संसाधन एक लेनदेन द्वारा रखे जाते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Hold-and-wait elimination: (1) All-or-nothing: declare all needed locks upfront, acquire atomically (difficult - often do not know all needs in advance). (2) Release before requesting (conservative): release all current locks when requesting new ones (causes restart overhead). Both are impractical for most real workloads. This is why most systems detect deadlocks rather than prevent hold-and-wait.

व्याख्या (हिन्दी) होल्ड-एंड-वेट उन्मूलन: (1) सभी या कुछ भी नहीं: सभी आवश्यक तालों को अग्रिम रूप से घोषित करें, परमाणु रूप से प्राप्त करें (कठिन - अक्सर सभी जरूरतों को पहले से नहीं जानते हैं)। (2) अनुरोध करने से पहले रिलीज़ करें (रूढ़िवादी): नए लॉक का अनुरोध करते समय सभी मौजूदा लॉक को रिलीज़ करें (ओवरहेड पुनरारंभ होने का कारण बनता है)। अधिकांश वास्तविक कार्यभार के लिए दोनों अव्यावहारिक हैं। यही कारण है कि अधिकांश सिस्टम होल्ड-एंड-वेट को रोकने के बजाय गतिरोध का पता लगाते हैं।

118

EN + हिं Easy

GB What is the no-preemption Coffman condition and how can preemption be introduced to break deadlocks?

IN नो-प्रीएम्प्शन कॉफ़मैन स्थिति क्या है और गतिरोध को तोड़ने के लिए प्रीएम्प्शन को कैसे लागू किया जा सकता है?

A

Preemption means stopping a transaction without completing it प्रीएम्प्शन का अर्थ है किसी लेन-देन को पूरा किए बिना रोकना

B

Preemption only works for shared locks प्रीएम्प्शन केवल साझा तालों के लिए काम करता है

C

Preemption requires explicit transaction consent प्रीएम्प्शन के लिए स्पष्ट लेनदेन सहमति की आवश्यकता होती है

D

No preemption means that resources (locks) cannot be forcibly taken from a transaction holding them. Preemption can be introduced by: aborting (preempting) a deadlocked transaction (victim selection) which is how deadlock resolution works - the DBMS forcibly rolls back a chosen victim transaction releasing its locks for other waiting transactions नो प्रीएम्प्शन का मतलब यह है कि संसाधनों (ताले) को उनके पास मौजूद लेनदेन से जबरन नहीं लिया जा सकता है। प्रीएम्प्शन को इसके द्वारा प्रस्तुत किया जा सकता है: एक गतिरोध वाले लेनदेन को निरस्त करना (पीड़ित चयन) जो कि गतिरोध समाधान कैसे काम करता है - डीबीएमएस जबरन चुने गए पीड़ित लेनदेन को वापस लाता है और अन्य प्रतीक्षा लेनदेन के लिए अपने ताले जारी करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) No-preemption elimination (deadlock resolution): when deadlock detected, the DBMS selects a victim transaction and aborts it (preempts its resources). This forcibly takes the victim transactionssource (locks) and releases them. The Wound-Wait prevention scheme also introduces preemption: older transactions can wound (abort) younger transactions holding needed resources.

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

119

EN + हिं Medium

GB What is the difference between deadlock detection frequency and deadlock detection latency?

IN डेडलॉक डिटेक्शन फ़्रीक्वेंसी और डेडलॉक डिटेक्शन विलंबता के बीच क्या अंतर है?

A

Detection frequency: how often the deadlock detector runs (e.g. every 100ms or every N lock requests); Detection latency: how long a deadlock persists before being detected and resolved (= time to next detection run + detection + abort time). Trade-off: higher frequency = lower latency but higher CPU overhead from running detection; lower frequency = lower overhead but deadlocked transactions blocked longer पता लगाने की आवृत्ति: डेडलॉक डिटेक्टर कितनी बार चलता है (उदाहरण के लिए प्रत्येक 100 एमएस या प्रत्येक एन लॉक अनुरोध); डिटेक्शन विलंबता: पता लगाने और हल करने से पहले कितने समय तक गतिरोध बना रहता है (= अगली डिटेक्शन रन का समय + डिटेक्शन + निरस्त समय)। ट्रेड-ऑफ: उच्च आवृत्ति = कम विलंबता लेकिन रनिंग डिटेक्शन से उच्च सीपीयू ओवरहेड; कम आवृत्ति = कम ओवरहेड लेकिन गतिरोध वाले लेनदेन लंबे समय तक अवरुद्ध रहते हैं

B

Frequency refers to number of deadlocks; latency refers to resolution time आवृत्ति से तात्पर्य गतिरोधों की संख्या से है; विलंबता का तात्पर्य समाधान समय से है

C

Detection frequency only applies to distributed deadlocks पता लगाने की आवृत्ति केवल वितरित गतिरोधों पर लागू होती है

D

They are the same concept वे एक ही अवधारणा हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Detection frequency vs latency trade-off: If detection runs every 5 seconds: deadlocks may persist up to 5 seconds (blocking other transactions for that duration). If detection runs every 10ms: very low latency but CPU overhead from constant graph scanning. MySQL InnoDB: detects deadlocks immediately after each lock wait (very low latency, efficient because it only checks affected transactions not the whole graph).

व्याख्या (हिन्दी) डिटेक्शन फ़्रीक्वेंसी बनाम विलंबता ट्रेड-ऑफ़: यदि डिटेक्शन हर 5 सेकंड में चलता है: गतिरोध 5 सेकंड तक बना रह सकता है (उस अवधि के लिए अन्य लेनदेन को अवरुद्ध करना)। यदि डिटेक्शन हर 10ms पर चलता है: बहुत कम विलंबता लेकिन निरंतर ग्राफ़ स्कैनिंग से CPU ओवरहेड। MySQL InnoDB: प्रत्येक लॉक प्रतीक्षा के तुरंत बाद गतिरोध का पता लगाता है (बहुत कम विलंबता, कुशल क्योंकि यह केवल प्रभावित लेनदेन की जांच करता है, पूरे ग्राफ की नहीं)।

120

EN + हिं Easy

GB What is cycle prevention vs cycle detection in the context of deadlock management strategies?

IN गतिरोध प्रबंधन रणनीतियों के संदर्भ में चक्र रोकथाम बनाम चक्र पहचान क्या है?

A

Prevention always outperforms detection रोकथाम हमेशा पता लगाने से बेहतर प्रदर्शन करती है

B

They are different terms for the same approach वे एक ही दृष्टिकोण के लिए अलग-अलग शब्द हैं

C

Detection is always preferred over prevention रोकथाम की तुलना में जांच को हमेशा प्राथमिकता दी जाती है

D

Cycle prevention: design the system so that cycles in the wait-for graph cannot form (e.g., lock ordering, Wait-Die, Wound-Wait, no-wait) - proactive approach that adds overhead to every transaction. Cycle detection: allow cycles to form then detect and break them periodically (e.g., wait-for graph cycle detection) - reactive approach lower per-transaction overhead but deadlocks persist briefly चक्र रोकथाम: सिस्टम को डिज़ाइन करें ताकि वेट-फॉर ग्राफ़ में चक्र न बन सकें (जैसे, लॉक ऑर्डरिंग, वेट-डाई, वाउंड-वेट, नो-वेट) - सक्रिय दृष्टिकोण जो हर लेनदेन में ओवरहेड जोड़ता है। चक्र का पता लगाना: चक्रों को बनने की अनुमति दें, फिर समय-समय पर उनका पता लगाएं और उन्हें तोड़ें (उदाहरण के लिए, ग्राफ़ चक्र का पता लगाने के लिए प्रतीक्षा करें) - प्रतिक्रियाशील दृष्टिकोण कम प्रति-लेन-देन ओवरहेड लेकिन गतिरोध थोड़े समय के लिए बना रहता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Prevention vs Detection trade-offs: Prevention overhead: every lock acquisition must check ordering rules or timestamp comparison - overhead even when no deadlock. Detection overhead: periodic graph scan or per-wait-graph update - overhead only when waits exist, but deadlocks briefly persist. Most OLTP DBMS use detection (InnoDB) because prevention (like lock ordering) is too restrictive for application developers to maintain.

व्याख्या (हिन्दी) रोकथाम बनाम जांच व्यापार-बंद: रोकथाम ओवरहेड: प्रत्येक लॉक अधिग्रहण को ऑर्डरिंग नियमों या टाइमस्टैम्प तुलना की जांच करनी चाहिए - कोई गतिरोध न होने पर भी ओवरहेड। डिटेक्शन ओवरहेड: आवधिक ग्राफ स्कैन या प्रति-प्रतीक्षा-ग्राफ अद्यतन - ओवरहेड केवल तभी जब प्रतीक्षा मौजूद होती है, लेकिन गतिरोध थोड़े समय के लिए बना रहता है। अधिकांश ओएलटीपी डीबीएमएस डिटेक्शन (इनोडीबी) का उपयोग करते हैं क्योंकि रोकथाम (जैसे लॉक ऑर्डरिंग) एप्लिकेशन डेवलपर्स के लिए बनाए रखने के लिए बहुत प्रतिबंधात्मक है।

DBMS — MCQ Practice