स्प्रिंग बूट में दृश्य में खुला सत्र: प्रेत खतरे

यहां हर कोई सही है, प्रत्येक अपने तरीके से, और इसलिए यहां हर कोई गलत है।
"द टेल ऑफ़ द थ्री" (ए। और बी। स्ट्रगत्स्की)

यदि आप स्प्रिंग डेटा JPA का उपयोग करते हैं, तो स्प्रिंग बूट 2 में अपग्रेड करने के बाद, जब आप एप्लिकेशन शुरू करते हैं, तो आप लॉग में एक नई चेतावनी देख सकते हैं:

स्प्रिंग.jpa.open-in-view डिफ़ॉल्ट रूप से सक्षम है। इसलिए, डेटाबेस क्वेरीज़ को व्यू रेंडरिंग के दौरान किया जा सकता है। स्पष्ट रूप से इस चेतावनी को अक्षम करने के लिए spring.jpa.open-in-view को कॉन्फ़िगर करें।

इस लेख में मैं यह समझाने की कोशिश करूंगा कि इसका क्या मतलब है, किसे दोष देना है और क्या करना है।

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

इस मोड में, हाइबरनेट सत्र को HTTP अनुरोध को संसाधित करने के सभी समय खुला रखा जाता है, जिसमें व्यू (JSON संसाधन या HTML पेज) बनाने की अवस्था भी शामिल है। यह व्यापार तर्क परत में लेनदेन करने के बाद प्रस्तुति परत में डेटा को लोड करने के लिए संभव बनाता है। उदाहरण के लिए, हम डेटाबेस से Article इकाई का अनुरोध करते हैं। लेख को टिप्पणियों के साथ प्रदर्शित किया जाना चाहिए। OSIV आपको HTML प्रदान करते समय बस getComments() इकाई विधि को कॉल करने की अनुमति देता है, और टिप्पणियों को एक अलग अनुरोध में लोड किया जाएगा। जब OSIV मोड अक्षम हो जाता है, तो हम एक LazyInitializationException प्राप्त करेंगे, क्योंकि सत्र पहले से ही बंद है और Article इकाई अब हाइबरनेट द्वारा प्रबंधित नहीं है। अधिकांश हाइबरनेट डेवलपर्स ने एक LazyInitializationException सामना किया है; OSIV आपको HTTP अनुरोध को संसाधित करने के किसी भी चरण में आवश्यक डेटा लोड करके इससे बचने की अनुमति देता है।

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

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

• ऑटो-कम मोड में लेन-देन के काम के बिना डेटाबेस प्रश्न, इसे बहुत अधिक लोड करना।
• जिम्मेदारियों का कोई पृथक्करण नहीं है, कोई भी एप्लिकेशन परत SQL क्वेरी उत्पन्न कर सकती है, जिससे परीक्षण कठिन हो जाता है।
• एक एन + 1 समस्या है जब एक इकाई से संबंधित प्रत्येक संग्रह को एक अलग अनुरोध में लोड किया जाता है।
• डेटाबेस के लंबे कनेक्शन फिर से उस पर लोड बढ़ाते हैं और थ्रूपुट को कम करते हैं।

ये OSIV मोड की काफी अप्रिय समस्याएं हैं और, ऐसा प्रतीत होता है, इसका उपयोग नहीं करने के लिए मजबूत तर्क। हालाँकि, डिफ़ॉल्ट रूप से इसे अक्षम करने के अनुरोध में , स्प्रिंग बूट डेवलपर्स ने भी अच्छे कारण दिए कि OSIV को नई परियोजनाओं के लिए सक्षम क्यों बनाया जाना चाहिए:

• पिछड़ी अनुकूलता। मौजूदा एप्लिकेशन जब स्प्रिंग बूट 2 में अपग्रेड होते हैं तो अक्षम OSIV के कारण त्रुटियों और बगों का सामना कर सकते हैं। इससे बचने के लिए, आपको केवल एकल मान spring.jpa.open-in-view सेट करने की आवश्यकता है। spring.jpa.open-in-view , लेकिन इससे नए संस्करण पर स्विच करना भी मुश्किल हो जाता है।
• शुरुआती के लिए उपयोग में आसानी और स्प्रिंग बूट के लिए एक त्वरित शुरुआत महत्वपूर्ण है। यदि OSIV अक्षम है, तो शुरुआती लोगों के लिए यह स्पष्ट नहीं हो सकता है कि क्यों इस तरह की एक सहज रूप से अपेक्षित चीज के रूप में संबंधित तत्वों का एक संग्रह प्राप्त करते समय एक इकाई विधि का उपयोग नहीं होता है। इसके बजाय, उपयोगकर्ता को एक LazyInitializationException प्राप्त होगी, इससे एक रनिंग एप्लिकेशन को उसका रास्ता धीमा हो जाएगा।
• OSIV आपको कोड सादगी, प्रयोज्यता और विकास की गति बढ़ाने की अनुमति देता है।
• OSIV के बिना किसी एप्लिकेशन को कैसे बनाया जाना चाहिए, इसके सरल उदाहरण खोजना कठिन है।
• OSIV के बिना, व्यापार तर्क परत को यह जानने की जरूरत है कि डेटा को यूआई में कैसे प्रस्तुत किया जाएगा, अर्थात, मूल इकाई के साथ-साथ डीटीओ को क्या आवश्यकता होगी या क्या संबंधित डेटा लोड किया जाना चाहिए। यह फिर से जिम्मेदारी के विभाजन का अभाव है।

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

ओपन सेशन इन व्यू मोड में काम करने के लिए कई उदाहरण और ट्यूटोरियल हैं, एक पूरे के रूप में आर्किटेक्चर स्पष्ट है: सेवा परत एक जेपीए इकाई का अनुरोध करती है, प्रस्तुति परत इसे सीधे JSON में एक मध्यवर्ती डीटीओ के माध्यम से अनुक्रमित करती है, या HTML पृष्ठ को प्रस्तुत करने के लिए इसके साथ डेटा का उपयोग करती है।

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

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

इसलिए, यदि आप इसे सही तरीके से करना चाहते हैं, तो आपको OSIV के बिना विकसित करने की आवश्यकता है। लेकिन अगर विकास की गति और कोड सरलता महत्वपूर्ण है, तो आप इस मोड का उपयोग कर सकते हैं, कुछ प्रदर्शन हानि के लिए इस्तीफा दे दिया।

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

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

क्या आप स्प्रिंग बूट एप्लिकेशन में OSIV का उपयोग करते हैं? यदि नहीं, तो डेटाबेस के साथ प्रस्तुति परत की बातचीत के लिए वास्तुकला कैसे व्यवस्थित है? इसके लिए किन तकनीकों और / या पुस्तकालयों का उपयोग किया जाता है?