हाइबरनेट कैश। अभ्यास

इसलिए, पिछले लेख की निरंतरता में , मैं वास्तविक जीवन की समस्याओं के बारे में बात करने की कोशिश करूँगा जो मुझे वास्तविक जीवन की परियोजनाओं में काम करते समय मिली थीं।

माइग्रेशन स्क्रिप्ट

शायद मेरे आवेदन में कैश के साथ काम करते समय सबसे आम समस्याओं में से एक एक चल रहे सर्वर पर माइग्रेशन स्क्रिप्ट को रोल करने की आवश्यकता है। वास्तव में, यदि ये स्क्रिप्ट किसी कार्यशील सर्वर के फ़ैक्टरी सत्रों के माध्यम से नहीं चलाई जाती हैं, तो इस फ़ैक्टरी के कैश को डेटाबेस में किए गए परिवर्तनों के बारे में नहीं पता है। इसलिए, हमें डेटा असंगति की समस्या मिलती है। इस समस्या को हल करने के कई तरीके हैं:

1. सर्वर रीस्टार्ट सबसे आसान और आमतौर पर अस्वीकार्य तरीका है;
2. कुछ तंत्रों के माध्यम से कैश को साफ़ करना शायद सादगी और विश्वसनीयता के लिए सबसे इष्टतम तरीका है। इस विधि को जेएमएक्स में एक वेब पेज या अन्य इंटरफेस में लाया जा सकता है और यदि आवश्यक हो तो कॉल किया जा सकता है। विधि का लचीलापन यह है कि यह एक बार लिखा जाता है, लेकिन कभी भी, कहीं भी उपयोग किया जाता है। यदि आपका कैश प्रदाता EHCache है और प्रदाता वर्ग SingletonEhCacheProvider है, तो आपका कोड इस तरह दिख सकता है:
   

   public String dumpKeys() { String regions[] = CacheManager.getInstance().getCacheNames(); StringBuilder allkeys = new StringBuilder(); String newLine = System.getProperty("line.separator"); for (String region : regions) { Ehcache cache = CacheManager.getInstance().getEhcache(region); allkeys.append(toSomeReadableString(cache.getKeys())); allkeys.append(newLine); } return allkeys.toString(); } 

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

क्वेरी कैश

क्वेरी कैश संभवतः पिछले लेख में सूचीबद्ध उन सभी के लिए सबसे अक्षम है। इसके कई कारण हैं:

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

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

  Criteria criteria = getSession().createCriteria(Plan.class); criteria.setProjection(Projections.projectionList() .add(Projections.groupProperty("status")) .add(Projections.rowCount()) ); criteria.setCacheable(true); 

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

कैश्ड आइटम हटाएं

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

 @Entity @Table(name = "shared_doc") @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) public class SharedDoc{ @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) private Set<User> users; } 

और उपयोगकर्ताओं में से एक को हटा दिया गया था, फिर हम उसका निष्कासन करते हैं:

 getSession().delete(user) 

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

 SharedDoc doc = (SharedDoc) session.load(SharedDoc.class, 1L); doc.getUsers().remove(user); session.delete(user); 

यह बहुत अच्छा काम करता है जब उपयोगकर्ता केवल एक संग्रह कैश में होता है - उपयोगकर्ता। लेकिन यह कार्य बहुत जटिल है जब इस तरह के बहुत सारे संग्रह हैं और वे विभिन्न संस्थाओं पर बिखरे हुए हो सकते हैं। कैश में छोड़ी गई वस्तुओं के साथ किसी भी क्रिया को आजमाते समय इसी तरह की समस्या ObjectNotFoundException को जन्म दे सकती है।

प्रतिस्पर्धी लेनदेन

कभी-कभी कैश आपको व्यवहार नहीं कर सकता जैसा कि आप प्रतिस्पर्धी लेनदेन के मामले में उम्मीद करते हैं। एक विशिष्ट मामले पर विचार करें:

 Session session1 = getSession(); Session session2 = getSession()); Transaction t = session1.beginTransaction(); Plan plan = (Plan) session1.load(Plan.class, 1L); System.out.println (plan.getName()); plan.setName(newName); t.commit(); t = session2.beginTransaction(); plan = (Plan) session2.load(Plan.class, 1L); System.out.println (plan.getName()); tx2.commit(); session1.close(); session2.close(); 

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

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