2011-10-31 16 views
10

के उपयोग के बावजूद एंड्रॉइड स्क्लाइट "डेटाबेस लॉक है" त्रुटियां मेरे पास एक ऐप (एंड्रॉइड 2.2 Google एपीआई लेवल 8) है जिसमें सामग्री प्रदाता से डेटा खींचने वाली कई गतिविधियां हैं (केवल डेटाबेस पहुंच चुनें)। इसमें किसी भी डेटाबेस लेखन कार्यों को स्वीकार करने वाले केंद्रीय अवरोधन कार्य कतार के साथ एक सेवा भी है; गतिविधियां एक सेवा अनुरोध (इरादे के रूप में) को आग लग सकती हैं जो एक थ्रेड और निष्पादन द्वारा अनुक्रमिक पुनर्प्राप्ति के लिए अवरुद्ध कतार पर एक कार्य रखती है। डाटाबेस लगभग 4 एमबी है।सामग्री प्रदाता और अनुक्रमिक डेटाबेस पहुंच

एक डेटाबेस डेटाबेस है जो सेवा को कॉल करने के लिए कॉल करने के तरीकों को कॉल करने के लिए उपयोग करता है; सभी एसक्यूएल लिखने डेटाबेस सहायक के भीतर किए जाते हैं।

  • सभी डेटाबेस लिखने एक लेनदेन से घिरे हुए हैं।
  • सभी डेटाबेस पढ़ता है कि कर्सर विधि के अंत में बंद हो गया है।
  • किसी भी गतिविधि में डेटाबेस ऑब्जेक्ट के लिए कोई संभाल नहीं है, वे केवल सामग्री प्रदाता या सेवा के माध्यम से संवाद कर सकते हैं।
  • कोई भी अलार्म प्रबंधक ने कार्यवाही की तरह कार्यवाही की - केवल कतार पर उचित कार्य को पॉप करने के लिए सेवा का उपयोग करें।
  • सेवा एकमात्र कक्षा है जिसमें डेटाबेस सहायक के लिए एक हैंडल है।
  • सभी डेटाबेस लेखन केवल कतार पर रखे गए कार्य के माध्यम से किए जाते हैं; मैंने थकावट से जांच की है कि एक कार्य निष्पादन अनुक्रमिक है जो एक SQLite डेटाबेस को समवर्ती लिखने से बचने के लिए आवश्यक है।

कार्य निष्पादन के एक भाग के दौरान मुझे लगातार 'यातायात' के कार्य निष्पादन द्वारा ट्रिगर किए गए डेटाबेस को लिखने के प्रयास में एक या दो "डेटाबेस लॉक किया गया" त्रुटियां मिलती हैं।

लॉक के स्रोत को ट्रैक करने का प्रयास करने में मैंने पाया कि dbhelper.in ट्रांज़ेक्शन(), dbhelper.isLockedByThisThread(), dbhelper.isLockedByOtherThread() का उपयोग करने में मदद नहीं की क्योंकि वे एक अप्रत्याशित डेटाबेस लॉक इंगित नहीं करेंगे।

मुझे पता चला कि लॉक को जल्दी से पहचानने में काम किया गया था, प्रारंभिक ट्रांज़ेक्शन() के साथ एक विधि बनाना था और सेट ट्रांज़ेक्शन किसी भी वास्तविक एसक्यूएल लेखन कोड के बिना असफल, एक कोशिश पकड़ने वाले ब्लॉक के भीतर जो समस्या को लॉग करेगा - हमेशा शुरूआत से ट्रिगर() ।

मैंने इस डेटाबेस लॉक जाल को प्रत्येक ब्लॉकिंग कतार कार्य विधियों के दोनों तरफ उम्मीद/आशा में रखा है कि मुझे एक एकमात्र अपराधी मिलेगा जो खत्म होने के बाद लॉक किए गए राज्य में डेटाबेस छोड़ रहा था। मुझे लगातार अपराधी नहीं मिला। डेटाबेस कॉल के माध्यम से कार्य कॉल की शुरुआत से नीचे ड्रिल करने के बाद मुझे पता चला कि पहले से चलने वाले कार्य द्वारा लॉक किए बिना एक डेटाबेस लॉक नीले रंग से बाहर हो सकता है (ये सभी कार्य समान एकवचन धागे के नीचे अनुक्रम में चलते हैं)।

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

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

क्या कोई भी कुछ सिद्धांत या गेटचा के बारे में सोच सकता है जिसे मैंने याद किया है?

क्या यह वास्तव में एंड्रॉइड के भीतर सामान्य है और बड़े SQLite डेटाबेस हैं जिन्हें आप कभी-कभी डेटाबेस लॉक प्राप्त करेंगे?

धन्यवाद

+0

कतार तंत्र के माध्यम से क्रमबद्ध डेटाबेस को पढ़ता है (चयन) या आपके लेखन लेनदेन में से किसी एक के साथ ओवरलैप पढ़ सकता है? यदि प्रतिबद्धता से ऐसा होता है तो असफल हो सकता है। यहां अध्याय 7 देखें http://www.sqlite.org/lockingv3.html – Stefan

उत्तर

0

मैं जाँच करेगा अगर कुछ गतिविधि है कि डीबी कॉल या अन्य गतिविधियों पर डीबी कॉल कहता है, केवल एक उदाहरण है। दूसरी तरफ यह कुछ हद तक खुद को बंद कर सकता है।

+0

तो, मेरे मामले में (जो ऊपर वर्णित है तो थोड़ा अलग है) मेरे पास दो क्रियाएं हैं जो अनुक्रमिक रूप से होती हैं, लेकिन एक दूसरे के बाद बहुत लंबी नहीं होती हैं। उपयोगकर्ता एक कदम करता है, करता है (यह ठीक काम करता है) लेकिन दूसरा एक काम करता है और बंद कर दिया जाता है। यह 5% कम होता है, और उस बिंदु पर कोई अन्य पृष्ठभूमि कोड बातचीत नहीं कर सकता है – Pyrodante

7

SQLite एकाधिक थ्रेड से अनुक्रमिक पहुंच की गारंटी देता है जब तक आप एक डेटाबेस कनेक्शन का उपयोग नहीं करते। आप डेटाबेस कनेक्शन को कैसे खोल और बंद कर रहे हैं?

मैं आम तौर पर स्टार्टअप पर डेटाबेस खोलने की सलाह देता हूं, और इसे कभी बंद नहीं करता हूं। बंद करने का कोई फायदा नहीं है, क्योंकि SQLite की लेन-देन प्रकृति का अर्थ है कि लिखने को यथासंभव जल्द से जल्द स्टोरेज में फ़्लश किया जाता है।

0
के साथ एंड्रॉयड और बड़ा SQLite डेटाबेस के भीतर

यह सामान्य वास्तविकता में है के संबंध कि आप समय-डेटाबेस ताले मिलेगा

?

नहीं, कभी-कभी डेटाबेस लॉक प्राप्त करना सामान्य नहीं है। अपनी कहानी पढ़ने से आप कहते हैं कि आपके पास डेटाबेस से खींचने वाली एक सेवा और सामग्री प्रदाता दोनों हैं, इसलिए यह संभव है कि आप डेटाबेस को दो एक्सेसों के बीच लॉक कर रहे हों।

जो मैं आम तौर पर करता हूं यह सुनिश्चित करता है कि मैं सामग्री प्रदाता के माध्यम से अपने सभी डेटाबेस एक्सेस को संभालता हूं। डेटाबेस में प्रवेश का एक बिंदु होने से आप यह सुनिश्चित कर सकते हैं कि प्रत्येक सॉफ्टवेयर घटक डीबी तक पहुंचने के लिए एक ही तर्क का उपयोग कर रहा है। क्या सामग्री सेवा प्रदाता के माध्यम से आपकी सेवा डीबी तक पहुंचना संभव होगा?

यह भी याद रखना अच्छा है कि एक सामग्री प्रदाता के पीछे अपना डीबी रखकर, इसे अभी भी कई धागे द्वारा एक बार में एक्सेस किया जा सकता है। यह सुनिश्चित करने के लिए कि आप डीबी को केवल एक थ्रेड तक पहुंच रहे हैं, आप अपने सामग्री प्रदाता के अंदर डीबी पर सिंक्रनाइज़ संरचना बना सकते हैं। जाहिर है यदि आप डीबी को बहुत लंबे समय तक लिखते/पढ़ते हैं, तो इस फैशन में लॉक करने से आपका ऐप पूरी तरह नष्ट हो जाएगा। सामग्री प्रदाता के अंदर अपने सभी डीबी कोड को डालने से आपको डिबगिंग का एक बिंदु भी मिल जाएगा जो आपको यह पता लगाने में मदद करेगा कि क्या एकाधिक धागे डीबी तक पहुंच रहे हैं।

संबंधित मुद्दे