मेरे पास @EJB एनोटेशन का उपयोग करते समय संभावित प्रदर्शन समस्या से संबंधित एक प्रश्न है। परिदृश्य@EJB इंजेक्शन बनाम लुकअप - प्रदर्शन समस्या
public class MyBean1 implements MyBean1Remote{
@EJB
private MyBean2Remote myBean2;
@EJB
private MyBean2Remote myBean3;
...
@EJB
private MyBean20Remote myBean20;
}
वहाँ अन्य सेम के लिए कई निर्भरता के साथ एक सेम है निम्नलिखित की कल्पना करें। ईजेबी स्पेक के मुताबिक अगर मैं किसी अन्य बीन को माइबियन 1 रिमोट इंजेक्ट करना चाहता हूं, तो कंटेनर को अपने पूल से सभी आवश्यक निर्भरताओं को माइबीन 1 रिमोट में इंजेक्ट करना होगा और फिर माईबीन 1 रिमोट स्टब के संदर्भ में इंजेक्ट करना होगा।
तो सुरक्षित 20 EJBs (myBean1 और उसके 19 निर्भरता)
public class MyAnotherBean implement MyAnotherRemote{
@EJB
private MyBean1Remote myBean1
}
Let लिए परिदृश्य कंटेनर की जरूरत है निम्नलिखित में कहना है कि ज्यादातर मामलों में हम myBean1 से प्रत्येक व्यापार विधि के अनुसार केवल एक निर्भरता का प्रयोग करेंगे। नतीजतन जब भी हम उस बीन को इंजेक्ट करना चाहते हैं तो हम कई अनावश्यक ईजेबी को रिजर्व करने के लिए कंटेनर को मजबूर करते हैं। आइए यह भी मान लें कि हम रिमोट बीन्स पर काम कर रहे हैं, इसलिए शायद कंटेनर को निर्भर बीन्स इंजेक्शन से पहले कुछ भार संतुलन एल्गोरिदम करने की भी आवश्यकता होगी।
सवाल:
नहीं है कि कारण अनावश्यक संसाधन आरक्षण और अधिक प्रदर्शन मुद्दे पर जबकि क्लस्टर वातावरण में सक्रिय हैं?
शायद अच्छा पुराना सेवा लोकेटर बेहतर समाधान हो सकता है क्योंकि इस दृष्टिकोण के साथ हम वास्तव में इसकी आवश्यकता होने पर विशिष्ट ईजेबी के लिए पूछेंगे?
+1 हां, यह भी एक अच्छा जवाब है :) उदाहरण स्वयं को इंजेक्शन नहीं दिया जाता है, लेकिन प्रॉक्सी है। इसके आगे, जैसा कि मेरे उत्तर में है, पूल में वास्तविक उदाहरणों में पहले से ही उनकी सभी निर्भरताओं का हल हो गया है। –