पारंपरिक सर्वलेट मॉडल में साथ इसे करने की कोशिश नहीं की है, यह आम तौर पर ऐसा होता है कि 1 अनुरोध 1 धागा से मेल खाती है है।
ये धागे आम तौर पर एक पूल से आते हैं जो सर्वलेट कंटेनर द्वारा प्रबंधित किया जाता है। सर्वलेट कंटेनर केवल नए अनुरोधों को संभाल सकता है जब तक कि इस पूल में मुफ्त धागे हों। जब तक आपका कोड अनुरोध संसाधित करने में व्यस्त रहता है, तब तक धागा मुक्त नहीं होता है।
कुछ स्थितियों में यह मॉडल को तोड़ने के लिए लायक हो सकता है। क्या होता है कि सर्वलेट कंटेनर प्रबंधित थ्रेड के माध्यम से सर्वलेट पर एक अनुरोध आता है, और आपका कोड तब एसिंक्रोनस निष्पादन के लिए पूछता है। फिर आप सर्वलेट अनुरोध से वापस आ सकते हैं और कंटेनर थ्रेड मुक्त हो जाएगा।
तुल्यकालिक अनुरोध प्रसंस्करण के विपरीत, यह कोई प्रतिक्रिया नहीं करेगा और कनेक्शन बंद नहीं करेगा। इसके बजाए, आप एसिंक संदर्भ को किसी अन्य थ्रेड पूल पर बंद कर सकते हैं, जो इसे उठा सकता है, और जब कुछ धागा इसे संभालने के लिए स्वतंत्र होता है, तो इसे सेवा दें और प्रतिक्रिया में लिखने में सक्षम होंगे।
एक उदाहरण:
@WebServlet(urlPatterns = "/somepath", asyncSupported = true)
public class AsyncServlet extends HttpServlet {
@EJB
private AsyncBean asyncBean;
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
AsyncContext asyncContext = request.startAsync();
// The following line will not block and return immediately
asyncBean.doAsyncStuff(asyncContext);
} // Shortly after this method has ended, thread will be returned to pool
}
AsyncBean
के साथ लागू किया जा रहा है:
@Stateless
public class AsyncBean {
@Asynchronous
public void doAsyncStuff(AsyncContext asyncContext) throws IOException {
asyncContext.getResponse().getWriter().write("test");
}
}
उपरोक्त कोड में, कहीं न कहीं कुछ ही समय बाद आप AsyncServlet#doGet()
विधि से लौटने के लिए, सर्वलेट धागा को लौटा दी जाएगी तालाब। AsyncBean#doAsyncStuff()
निष्पादित करने के लिए 'अनुरोध' (कार्य) को ईजेबी थ्रेड पूल के लिए कतार में रखा जाएगा।
क्यों उत्तर और जब आप इसका उपयोग करेंगे तो यह सीधा नहीं है। यदि आप केवल थ्रेड को संरक्षित करना चाहते हैं तो उपर्युक्त मामले में आप एक थ्रेड पूल से दूसरे के लिए एक थ्रेड का आदान-प्रदान करेंगे (इस मामले में सर्वलेट पूल बनाम ईजेबी एसिंक पूल) और शुद्ध लाभ इतना नहीं होगा। आप अपने सर्वलेट थ्रेड पूल को अतिरिक्त थ्रेड भी दे सकते हैं।
अधिक उन्नत परिदृश्यों में, आप अनुरोधों के अधिक सुव्यवस्थित प्रबंधन कर सकते हैं; उन्हें कई कार्यों में विभाजित करें और उन कार्यों को थ्रेड पूल सेवा दें। जैसे 10 थ्रेड द्वारा संभाली गई 10 एमबी फ़ाइल के लिए 100 डाउनलोड अनुरोधों की कल्पना करें कि राउंड-रॉबिन प्रत्येक अनुरोध के लिए 100KB एक समय भेजता है।
फिर भी एक और आवेदन एक अनुरोध है जिसे बाहरी सिस्टम से डेटा की प्रतीक्षा करने की आवश्यकता होती है, और जहां यह बाहरी प्रणाली एक संदेश भेजने में सक्षम है जिसे अनुरोधकर्ता को वापस रिले किया जा सकता है। अर्थात। एक डेटाबेस कॉल यहां समझ में नहीं आएगा, क्योंकि आपको वैसे भी प्रतिक्रिया के लिए इंतजार कर रहे एक और थ्रेड की आवश्यकता होगी। फिर आप एक धागे को फिर से बदल देंगे। लेकिन अगर आपको आने वाली ईमेल कहने की प्रतीक्षा करनी है, तो एक थ्रेड किसी भी ईमेल के लिए इंतजार कर सकता है और किसी भी निलंबित अनुरोध के लिए रिले कर सकता है।
बहुत धन्यवाद अरजन, पहला अनुच्छेद वास्तव में स्पष्ट और समझ में आता है। –
मैं पूरी तरह से समझ नहीं पा रहा हूं कि कैसे एक थ्रेड को एक पूल से दूसरे में ले जाना एक स्केलेबिलिटी पॉइंट व्यू से एक अंतर बना सकता है। मैं सर्वर श्रोता धागे को पूल में लौटने में बिंदु देखता हूं, लेकिन मुझे वास्तव में पता नहीं है कि क्या यह आपके एप्लिकेशन स्केलेबिलिटी को बहुत बेहतर बना सकता है। –
धागे का आदान-प्रदान स्केलेबिलिटी में मदद नहीं करेगा, लेकिन डाउनलोड उदाहरण देखें। कुछ धागे कई एसिंक्रोनस कनेक्शन को खिलाने में सक्षम हो सकते हैं। अगर अनुरोध को कई कार्यों में विभाजित किया जा सकता है जिन्हें कतारबद्ध किया जा सकता है और ऐसा, इस मोड पर विचार करने के लिए यह उचित हो सकता है। अन्यथा, वास्तव में, बहुत अधिक अपेक्षित लाभ नहीं हैं। –