एसक्यूएल सर्वर सीएलआर एकीकरण जीवन चक्र क्या है?

Question

सीएलआर (.NET) ऑब्जेक्ट्स SQL ​​सर्वर में प्रबंधित कैसे हैं?

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

SQL सर्वर इसका कैसा व्यवहार करता है? क्या यह स्थिर सदस्यों (गैर-विधि) को भी अनुमति देता है? यदि हां, तो यह स्मृति में उन्हें कितनी देर तक बनाए रखता है? क्या यह हर सीएलआर कॉल के बाद सबकुछ इकट्ठा करता है? यह समवर्ती संभाल कैसे करता है?

Answer 1

में "प्रो SQL सर्वर 2005 सभाओं" रॉबिन Dewson और जूलियन स्किनर द्वारा, यह कहना है कि "सभाओं एक डेटाबेस में लोड, अन्य डेटाबेस वस्तुओं की तरह, एक डेटाबेस उपयोगकर्ता के स्वामित्व में हैं। एक ही उपयोगकर्ता के स्वामित्व वाले सभी विधानसभाओं एक ही डेटाबेस एक ही ऐपडोमेन के भीतर चलाएगा। एक अलग उपयोगकर्ता के स्वामित्व वाली असेंबली एक अलग ऐपडोमेन के भीतर चलेगी। "

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

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

Answer 2

अपने युक्त प्रकार के लिए सी # विशिष्टता 3,0 (5.1.1)

एक स्थिर चर स्थिर निर्माता (§10.12) के क्रियान्वयन से पहले अस्तित्व में आता है से, और जब अस्तित्व समाप्त हो जाता संबंधित अनुप्रयोग डोमेन मौजूद है।

निश्चित रूप से यह प्रत्येक कॉल के बाद पूरे एप्लिकेशन डोमेन को बंद नहीं करेगा क्योंकि यह थोड़ा अक्षम होगा। तो हाँ, ये स्थैतिक वस्तुएं तब तक रहती हैं जब तक डेटाबेस बंद नहीं होता है या फिर से शुरू नहीं होता है।

Answer 3

यहां कुछ जानकारी दी गई है जो मुझे मिली है।

Troubles with shared state and anonymous delegates in SQLCLR

इतना ही साझा किया जाता है राज्य एक गैर असुरक्षित विधानसभा में अनुमति नहीं है, लेकिन गुमनाम प्रतिनिधियों (दुर्भाग्य से) यह "साझा राज्य" प्रतिबंध ट्रिगर।

Answer 4

एसक्यूएल सर्वर असुरक्षित अनुमति स्तर के साथ असेंबली तैनात होने पर स्थिर पाठक सदस्यों को अनुमति देता है।

व्यावहारिक रूप से ऑब्जेक्ट्स स्मृति में तब तक बनाए रखा जाता है जब तक कि SQL सेवा बंद/पुनरारंभ नहीं हो जाती।

समेकन के संबंध में, आपकी वस्तु और विधियों को हर जगह थ्रेड-सुरक्षित होना चाहिए।

उदाहरण के लिए:

public static class MyCLRClass 
{ 
    private static readonly ReaderWriterLock rwlock = new ReaderWriterLock(); 
    private static readonly ArrayList list = new ArrayList(); 

    private static void AddToList(object obj) 
    { 
     rwlock.AcquireWriterLock(1000); 
     try 
     { 
      list.Add(obj); 
     } 
     finally 
     { 
      rwlock.ReleaseLock(); 
     } 
    } 

    [SqlProcedure(Name="MyCLRProc")] 
    public static void MyCLRProc() 
    { 
     rwlock.AcquireReaderLock(1000); 
     try 
     { 
      SqlContext.Pipe.Send(string.Format("items in list: {0}", list.Count)); 
     } 
     finally 
     { 
      rwlock.ReleaseLock(); 
     } 
    } 
} 

मैं SQL CLR में ऐसी बातों का उपयोग करें और यह काम करता है।

Answer 5

कल्पना कीजिए नहीं; आप बहुत स्थिर सदस्य बना सकते हैं। लेकिन, उन्हें readonly के रूप में चिह्नित करने की आवश्यकता है, जिनके पास SAFE या EXTERNAL_ACCESS हैं। केवल UNSAFE के रूप में चिह्नित एक असेंबली लिखने योग्य स्थिर सदस्य हो सकती है। और यह प्रतिबंध स्थैतिक सदस्यों की प्रकृति के कारण है: धागे और सत्रों के बीच साझा किए गए हैं।

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

यह अपेक्षा की जानी चाहिए कि एक बार लोड होने पर, कक्षा (और ऐप डोमेन जो इसमें रहता है) स्मृति में तब तक रहेगा जब तक कि SQL सर्वर सेवा पुनरारंभ नहीं हो जाती है या PERMISSION_SET मान बदल जाता है। लेकिन इसकी गारंटी नहीं है। यह पेज, Memory Usage in SQL CLR के अनुसार:

जब वहाँ सर्वर पर स्मृति दबाव है, SQL CLR स्पष्ट रूप से चल रहा है कचरा संग्रहण द्वारा स्मृति जारी करने और यदि आवश्यक हो, appdomains उतारने की कोशिश करेंगे।

• वे अप्रत्याशित पैदा कर सकता है:
  • वे कैशिंग (बहुत शांत)
  • वे और अधिक खतरनाक हो सकता है के लिए इस्तेमाल किया जा सकता है:

तो तुम स्थिर सदस्यों के बारे में दोनों मामलों में सही हैं व्यवहार

वे स्मृति को जोड़ सकते हैं क्योंकि उन्हें निहित करने के लिए कोई अंतर्निहित तंत्र या प्राकृतिक घटना नहीं है क्योंकि कक्षा सक्रिय रहती है।

और, CLR दिनचर्या के लिए उपलब्ध स्मृति की मात्रा बहुत है कि क्या एसक्यूएल सर्वर 32 या 64 बिट है पर निर्भर करता है, और क्या आप एसक्यूएल सर्वर का उपयोग कर रहे 2005/2008/2008 R2 या SQL Server 2012 का उपयोग कर/2014. SQLCLR को कितनी मेमोरी के साथ खेलना है, इस बारे में अधिक जानकारी के लिए, SQL Server 2012 Memory और Memory Usage in SQL CLR देखें (उद्धरण के ऊपर पोस्ट किए गए पहले लिंक के समान)।