वेब अनुप्रयोग में एंटीटी मैनेजर प्रति एचटीपीशन बनाने के साथ संभावित मुद्दे

Question

एप्लिकेशन में से एक में, मैंने देखा कि एंटीटी मैनेजर 'प्रति उपयोगकर्ता HttpSession' बनाया गया है और EntityManagerFactory केवल एक बार बनाया गया है।

वसंत या ईजेबी आवेदन में उपयोग नहीं किया जाता है। इकाई प्रबंधक को http सत्र में कैश किया गया है और जब सत्र अमान्य हो गया है।

public EntityManager getEntityManager() { 
    //Logic to get entity manger from session 
    //If its present , then return 
    //Else create new one , entityManagerFactory.createEntityManager(); 
    //Put it into session and then return. 
    //Returned entity manager is not closed by dao methods , 
    //but clear() is invoked 
} 

1. इस डिजाइन के साथ संभावित समस्याओं क्या हैं।
2. क्या होगा यदि 100K उपयोगकर्ता एक साथ एप्लिकेशन में लॉग इन करते हैं, तो क्या हम जेडीबीसी कनेक्शन से बाहर हो जाएंगे?
3. क्या प्रत्येक इकाई प्रबंधक के पास एक अलग जेडीबीसी कनेक्शन है?

Answer 1

2 और 3 का उत्तर हाँ है। क्यू 1 के लिए:

एक समस्या यह है कि आपके पास यह समस्या होगी कि सत्र आमतौर पर 2 से 24 घंटों (या अधिक) से पिछली बार पहुंचने के बाद कहीं भी रहता है। इसका मतलब है कि आपका सत्र ऑब्जेक्ट EntityManager को खोलने के लिए प्रयास करेगा और EntityManager जेडीबीसी कनेक्शन को जिंदा और अनन्य रखने के लिए प्रयास करेगा। यहां तक ​​कि प्रति घंटे 50 उपयोगकर्ताओं के साथ, आपके पास इसके कारण पहले ही अपवाद और त्रुटि 500 ​​पेज होंगे।

मेरा मानना ​​है कि सर्ज बलेस्टा ने इस दृष्टिकोण के कारण अन्य प्रमुख समस्याओं को सूचीबद्ध किया है।

एक बहुत ही सुरक्षित समाधान एक स्थिर ThreadLocal<EntityManager> सिंगलटन पहुंच और javax.servlet.Filter सभी यूआरएल पर एक कोशिश-अंतराल कथन के साथ है जो सुनिश्चित करता है कि प्रत्येक अनुरोध पर EntityManager ठीक से बंद हो। अन्यथा जो भी अपवाद हो सकता है वह कनेक्शन को लटकने और अतिरिक्त समस्याओं का कारण बन जाएगा।

Answer 2

कृपया ऐसा न करें: आप वेब परत में दृढ़ता परत को सीधे बांध रहे हैं जब सर्वोत्तम प्रथाओं में केवल एक परत और केवल आसन्न के बीच स्तरित अनुप्रयोगों (ढीले) लिंक के साथ डिजाइन करने की अनुशंसा की जाती है।

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

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

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