यदि मेरा वेब एप्लिकेशन और ईजेबी एप्लीकेशन एक ही मशीन (उसी जेवीएम पर) पर है और सभी ईजेबी कॉल स्थानीय कॉल हैं, तो ThreadLocal का उपयोग वेब से ईजेबी तक जानकारी पास करते समय कोई समस्या पैदा करेगा?एंटरप्राइज़ एप्लिकेशन में थ्रेडलोकल उपयोग
कोई कामकाज अगर ईजेबी कॉल दूरस्थ हैं? ThreadLocal जानकारी वेब एप्लिकेशन से ejb एप्लिकेशन पर उपलब्ध होगी? ThreadLocal का उपयोग ऐसे परिदृश्य में किया जा सकता है?
पहले प्रश्न के लिए, जब तक आप प्रत्येक कॉल के अंत में थ्रेडलोकल चर को हटाते हैं तब तक कोई समस्या नहीं होती है। यह महत्वपूर्ण है क्योंकि कंटेनर (सर्वलेट या ईजेबी) आम तौर पर उपयोगकर्ता थ्रेडपूल और इसलिए धागे का पुन: उपयोग करते हैं, इसके दो प्रभाव होते हैं: एक "कॉल" पिछली कॉल से आने वाली थ्रेडलोकल जानकारी देख सकता है, और यदि आप JVM को रोक दिए बिना कंटेनर से कोई ऐप निकालते हैं कुछ वर्ग कचरा नहीं हो सकते हैं क्योंकि उन्हें अभी भी कंटेनर थ्रेड द्वारा संदर्भित किया जाता है। तो डेटा को थ्रेडलोकल में आज़माएं/आखिर में ब्लॉक करें और आखिर में हटा दें।
यहाँ एक पोस्ट समस्या को संभालने के लिए एक ही रास्ता दिखा रहा है: ThreadLocal in web applications
दूसरे प्रश्न के लिए के रूप में डेटा है threadlocal यह एक दूरस्थ कॉल के साथ नहीं आएगा, तो आप अपने इंटरफेस के लिए एक पैरामीटर जोड़ने के लिए, निकालने है threadlocal एक तरफ डेटा और किसी भी मुद्दे दूसरी तरफ इसे पुन: ...
यह निर्भर करता है कि आप कौन सी जानकारी पारित कर रहे हैं! पहला सवाल यह बहुत सामान्य है। मैं ThreadLocal here से संबंधित JavaDoc पढ़ने का सुझाव देता हूं।
थ्रेडलोकल एप्लिकेशन के सर्वर पक्ष से रहता है और थ्रेड-सुरक्षित को आपकी थ्रेड ऑब्जेक्ट्स की कॉल करने के लिए उपयोग किया जाता है।
थ्रेडलोकल का जावाडोक लगभग पर्याप्त नहीं होगा। आप निश्चित रूप से नहीं जानते कि सर्वर थ्रेड का प्रबंधन कैसे करेगा, उन्हें अनुरोधों के साथ बाध्य करेगा, आदि – ymajoros
सभी EJB कॉल स्थानीय कॉल कर रहे हैं, ThreadLocal के उपयोग पैदा करेगा, जबकि
नहीं, आपने अपने प्रश्न का उत्तर दिया है। चूंकि कॉल स्थानीय हैं, इसलिए उन्हें एक थ्रेड के संदर्भ में निष्पादित किया जाता है।
कोई कामकाज अगर ईजेबी कॉल दूरस्थ हैं?
दूरस्थ कॉल के मामले में, जावा ईई कंटेनर एक अन्य JVM, यह आने वाले RMI अनुरोध को पूरा करने के लिए अपने स्वयं धागे अंडे जाएगा में चलाया जाएगा, वहाँ एक दूरस्थ जावा ईई कंटेनर धागा बारे में पता करने के लिए कोई रास्ता नहीं है स्थानीय चर जो दूसरी तरफ घोषित किए गए थे। इसे पैरामीटर ऑब्जेक्ट के रूप में पास करें।
स्थानीय कॉल के लिए, ThreadLocal ठीक काम करना चाहिए, जब तक कि सब कुछ एक ही थ्रेड में किया जाता है।
दूरस्थ कॉल के लिए, जो संभावित रूप से किसी भिन्न सर्वर पर चल सकता है, आपको कुछ और के साथ आने की आवश्यकता होगी। या तो सभी मानों को पैरामीटर के रूप में पास करें (जो काम करेगा, लेकिन कोड में जटिलता पेश करेगा) या वितरित कैश जैसे कुछ का उपयोग करें, उदा। Hazelcast, जो वैश्विक HashMap जैसा कार्य करेगा, जो सभी क्लस्टर नोड्स तक पहुंच प्राप्त करता है।
ईजेबी 3.1 का उपयोग करते समय आप अपने context data का उपयोग कर EJBContext में प्रासंगिक जानकारी पास कर सकते हैं। यह सिर्फ Map<String,Object> है।
ईजीबी संदर्भों में थ्रेडलोकल का उपयोग नहीं किया जाना चाहिए।कोई गारंटी नहीं दे सकता कि ईजेबी विधि के आविष्कार सभी एक ही धागे पर हैं (बेशक होना चाहिए)।
ईजेबी में TransactionSyncrhonizationRegistry पर एक अलग दृष्टिकोण कॉल है। अधिक जानकारी के लिए Explanation/Usage देखें।
ThreadLocal वेब अनुप्रयोगों में 100% निश्चितता के साथ उपयोग नहीं किया जा सकता है। आपके पास बस गारंटी नहीं है कि एक थ्रेड का उपयोग एक सत्र के लिए किया जाएगा। मेरे दृष्टिकोण में सुरक्षा छेद खोजने के लिए यह बहुत मुश्किल हो सकता है!
मेरे लिए काम नहीं करता है, यह हमेशा null देता है!
मैंने TransactionSynchronizationRegistry भी कोशिश की, लेकिन मुझे null भी मिला।
काम करने वाली एकमात्र चीज जेएएएस को वर्कअराउंड के रूप में उपयोग कर रही है। लेकिन यह एक अच्छा समाधान नहीं है।
धन्यवाद। मूल रूप से कोड को संशोधित किए बिना मौजूदा ईई एप्लिकेशन में बहुभाषी क्षमताओं को जोड़ रहा हूं। मैं भाषा स्थापित करूँगा HTTP सत्र में जानकारी और फिर 'थ्रेडलोकल' में मान सेट करने के लिए उस जानकारी का उपयोग HTTP सत्र में करें। इसलिए एप्लिकेशन में एक जगह (HTTPFilter शायद) की पहचान करनी होगी जिसे प्रत्येक अनुरोध से पहले बुलाया जाता है और HTTPSession से 'थ्रेडलोकल' में मान सेट करता है। यह सुनिश्चित करेगा कि यह ईजेबी में उपलब्ध है जिसे अंततः डेटाबेस पेटामीटर के रूप में पास किया जाएगा। –
यह सुनिश्चित करेगा कि अगर मैं इसे हटा नहीं देता हूं, तो यह हर बार ओवरराइट किया जाएगा। आपके उत्तर के लिए धन्यवाद। –