සේවාදායකයන් ක්‍රියා කරන්නේ කෙසේද? ස්ථාපනය, සැසි, හවුල් විචල්‍යයන් සහ බහු කියවීම්

මා සතුව වෙබ් සේවාදායකයක් ඇති අතර එය සේවාදායක ගණනක් තබා ඇත. එම සේවාදායකයන් අතර තොරතුරු ලබා ගැනීම සඳහා මම සැසිය සහ නිදර්ශන විචල්‍යයන් සකසමි.

දැන්, පරිශීලකයින් දෙදෙනෙකු හෝ වැඩි ගණනක් මෙම සේවාදායකයට ඉල්ලීමක් එවන්නේ නම් සැසි විචල්‍යයන්ට කුමක් සිදුවේද?
ඒවා සියල්ලම සියලු පරිශීලකයින් සඳහා පොදු වේද? නැතහොත් ඒවා එක් එක් පරිශීලකයාට වෙනස් වේවිද?
ඔවුන් වෙනස් නම්, සේවාදායකයාට විවිධ පරිශීලකයින් අතර වෙනස හඳුනාගත හැකි වූයේ කෙසේද?

තවත් සමාන ප්‍රශ්නයක් නම්, nකිසියම් සේවාදායකයකට ප්‍රවේශ වන පරිශීලකයින් සිටී නම්, මෙම සේවාදායකය ක්ෂණිකව ලබා ගන්නේ පළමු පරිශීලකයා එයට ප්‍රවේශ වූ පළමු අවස්ථාව පමණක් ද නැතහොත් එය සියලු පරිශීලකයින් සඳහා වෙන වෙනම ක්ෂණිකව ලබා දෙන්නේ ද?
වෙනත් වචන වලින් කිවහොත්, නිදර්ශන විචල්‍යයන්ට කුමක් සිදුවේද?

සර්වට්කොන්ටෙක්ස්ට්

සර්වට් බහාලුම ( අපාචේ ටොම්කාට් වැනි ) ආරම්භ වූ විට, එය එහි සියලුම වෙබ් යෙදුම් යෙදවීම සහ පැටවීම සිදු කරයි. වෙබ් යෙදුමක් පටවන විට, සර්වට් බහාලුම ServletContextඑක් වරක් නිර්මාණය කර එය සේවාදායකයේ මතකයේ තබා ගනී. වෙබ් යෙදුම ගේ web.xmlහා ඇතුළත් සියලු web-fragment.xmlගොනු කියවූ අතර, එක් එක් <servlet>, <filter>හා <listener>සොයා (හෝ ග්රන්ථ එක් එක් පන්තියට @WebServlet, @WebFilterහා @WebListenerපිළිවෙළින්) වරක් instantiated මෙන්ම සේවාදායකය මතකයේ තබා ඇත. සෑම ක්ෂණික පෙරණයක් සඳහාම, එහි init()ක්‍රමය නව එකක් සමඟ ක්‍රියාත්මක වේFilterConfig .

කරන විට Servletසතුව <servlet><load-on-startup>හෝ @WebServlet(loadOnStartup)වැඩි වටිනාකමක් වඩා 0, එසේ නම් එහි init()ක්රමය ද සමග නව ආරම්භක කාලය තුළ පළ කළහ ඇත ServletConfig. එම සේවාදායකයන් ආරම්භ කරනු ලබන්නේ එම අගය අනුව නියම කර ඇති අනුපිළිවෙලෙනි ( 11 වන, 22 වන, ආදිය). එම අගය එකකට වඩා වැඩි servlet සඳහා නිශ්චිත නම්, එසේ නම් එම servlets එක් එක් ඔවුන් පෙනී සමාන පිණිස රුවා ඇත web.xml, web-fragment.xmlහෝ @WebServletclassloading. "ආරම්භක-පැටවීමේ ආරම්භක අගය" නොමැති init()විට, HTTP ඉල්ලීම පළමු වරට එම සේවාදායකයට පහර දෙන සෑම විටම ක්‍රමය ක්‍රියාත්මක වේ.

ඉහත විස්තර කර ඇති ආරම්භක පියවරයන් සියල්ලම සමඟ සර්වට් බහාලුම අවසන් වූ විට, ඉන්වොයිස් ServletContextListener#contextInitialized()කරනු ලැබේ.

පහළ වූ විට servlet රුවනයකි වෑල්ව වැසී, එය, සියලු වෙබ් යෙදුම් වඩසටහනක් වන අල්ලාහ් destroy()එහි සියලු ආරම්භනය servlets සහ පෙරහන් ක්රමය, සහ සියලු ServletContext, Servlet, Filterහා Listenerඅවස්ථා දවසක් ලස්සන කලා වේ. අවසාන වශයෙන් ServletContextListener#contextDestroyed()කැමැත්ත ඉල්ලා සිටිනු ඇත.

HttpServletRequest සහ HttpServletResponse

සර්වට් බහාලුම කිසියම් වරාය අංකයකින් HTTP ඉල්ලීම්වලට සවන් දෙන වෙබ් සේවාදායකයකට අමුණා ඇත (වරාය 8080 සාමාන්‍යයෙන් සංවර්ධනයේදී භාවිතා වන අතර නිෂ්පාදනයේ 80 වරාය වේ). සේවාදායකයෙක් (උදා: වෙබ් බ්‍රව්සරයක් ඇති පරිශීලකයෙකු හෝ ක්‍රමලේඛිකව භාවිතා කරනURLConnection ) HTTP ඉල්ලීමක් යවන විට, සර්වට් බහාලුම නව HttpServletRequestසහ HttpServletResponseවස්තූන් නිර්මාණය Filterකර ඒවා දාමයේ අර්ථ දක්වා ඇති ඕනෑම දෙයක් හරහා යවයි Servlet.

මෙම නඩුවේ පෙරහන් මෙම doFilter()ක්රමය උපයෝගී කර ඇත. සර්වට් බහාලුම් කේතය ඇමතූ විට chain.doFilter(request, response), ඉල්ලීම සහ ප්‍රතිචාරය ඊළඟ පෙරණය වෙත ඉදිරියට යයි, නැතහොත් ඉතිරි පෙරහන් නොමැති නම් සේවාදායකයට පහර දෙන්න.

මෙම නඩුවේ servlets මෙම service()ක්රමය උපයෝගී කර ඇත. පෙර සැකසුමක් ලෙස, එක් වන මෙම ක්රමය මගින් තීරණය doXxx()ක්රම මත පදනම් පතා request.getMethod(). තීරණය කරන ලද ක්‍රමය සේවාදායකයෙන් නොමැති නම්, ප්‍රතිචාරයේ දී HTTP 405 දෝෂයක් නැවත ලබා දෙනු ලැබේ.

ඉල්ලීම් වස්තුව HTTP ඉල්ලීම පිළිබඳ එහි URL, ශීර්ෂයන්, විමසුම් නූල් සහ ශරීරය වැනි සියලු තොරතුරු සඳහා ප්‍රවේශය සපයයි. ප්‍රතිචාර වස්තුව මඟින් ඔබට අවශ්‍ය ආකාරයට HTTP ප්‍රතිචාරය පාලනය කිරීමට සහ යැවීමට හැකියාව ලබා දෙයි, නිදසුනක් ලෙස, ශීර්ෂයන් සහ ශරීරය සැකසීමට ඔබට ඉඩ සලසයි (සාමාන්‍යයෙන් JSP ගොනුවකින් ජනනය කරන ලද HTML අන්තර්ගතය සමඟ). HTTP ප්‍රතිචාරය කැපවී අවසන් වූ විට, ඉල්ලීම සහ ප්‍රතිචාර වස්තු ප්‍රතිචක්‍රීකරණය කර නැවත භාවිතා කිරීම සඳහා ලබා දේ.

HttpSession

සේවාදායකයෙක් පළමු වරට වෙබ් ඇප් වෙත පිවිසෙන විට සහ / හෝ HttpSession ලබා ගත් විට request.getSession(), සර්වට් බහාලුම නව HttpSessionවස්තුවක් නිර්මාණය කරයි , දිගු හා අද්විතීය හැඳුනුම්පතක් ජනනය කරයි (ඔබට එය ලබා ගත හැකිය session.getId()), සහ එය සේවාදායකයේ ගබඩා කරයි මතකය. මෙම servlet රුවනයකි ද සකසයි Cookieතුළ Set-Cookieසමග HTTP ප්රතිචාරයක් ශීර්ෂ JSESSIONIDඑහි නම හා අද්විතීය සැසිය හැඳුනුම්පත එහි අගය ලෙස.

දක්වා ඇති පරිදි HTTP කුකී පිරිවිතර (කොන්ත්රාත්තුවක් ඕනෑම යහපත් වෙබ් බ්රවුසරයක් සහ වෙබ් සේවාදායකය පිළිපැදිය යුතුය), සේවාලාභියා (වෙබ් බ්රවුසරය) තුළ පසු ඉල්ලීම් මෙම කුකිය ආපසු යැවීමට අවශ්ය වේ Cookieකල් කුකී වලංගු ලෙස සඳහා ශීර්ෂ ( එනම් අද්විතීය හැඳුනුම්පත අඩු නොකළ සැසියකට යොමු විය යුතු අතර වසම සහ මාර්ගය නිවැරදි වේ). ඔබගේ බ්‍රව්සරයේ සාදන ලද HTTP ගමනාගමන මොනිටරය භාවිතා කරමින්, ඔබට කුකිය වලංගු දැයි තහවුරු කර ගත හැකිය (Chrome / Firefox 23+ / IE9 + හි F12 ඔබන්න, සහ Net / Network පටිත්ත පරීක්ෂා කරන්න). සර්වට් බහාලුම Cookieකුකියේ නම සහිතව සිටීම සඳහා පැමිණෙන සෑම HTTP ඉල්ලීමකම ශීර්ෂකය පරීක්ෂා කර සේවාදායකයේ මතකයෙන් JSESSIONIDසම්බන්ධය ලබා ගැනීමට එහි අගය (සැසි හැඳුනුම්පත) භාවිතා කරයි HttpSession.

මෙම HttpSessionඑය සඳහන් වඩා ඉකුත් අගය අකර්මන්යව (එනම්, ඉල්ලීම භාවිතා නොවේ) වී ඇති තෙක් ජීවත් නවාතැන් පහසුකම් <session-timeout>දී සැකසුම, web.xml. කල් ඉකුත් වීමේ අගය පෙරනිමිය විනාඩි 30 කි. එබැවින්, සේවාදායකයා නියමිත වේලාවට වඩා වැඩි කාලයක් වෙබ් යෙදුමට නොපැමිණෙන විට, සේවාදායක බහාලුම සැසිය ඉවත දමයි. සෑම පසුකාලීන ඉල්ලීමකටම, කුකිය නියම කර තිබුණද, එකම සැසිවාරයට තවදුරටත් ප්‍රවේශ නොවනු ඇත; සේවාදායක බහාලුම නව සැසියක් නිර්මාණය කරයි.

සේවාදායකයාගේ පැත්තෙන්, බ්‍රවුසර උදාහරණය ක්‍රියාත්මක වන තාක් සැසි කුකිය සජීවීව පවතී. එබැවින්, සේවාදායකයා බ්‍රව්සරය (සියලු ටැබ් / කවුළු) වසා දැමුවහොත්, සැසිය සේවාදායකයාගේ පැත්තෙන් ඉවත දමනු ලැබේ. නව බ්‍රව්සර අවස්ථාවක, සැසිය හා සම්බන්ධ කුකිය නොපවතින බැවින් එය තවදුරටත් යවනු නොලැබේ. මෙය HttpSessionසම්පූර්ණයෙන්ම නව සැසි කුකියක් භාවිතා කරමින් සම්පූර්ණයෙන්ම නව නිර්මාණය වීමට හේතු වේ .

කෙටියෙන් කිවහොත්

• මෙම ServletContextවෙබ් යෙදුම ජීවිත තාක් කාලයක් සඳහා ජීවිත. හි ඇති සියලුම ඉල්ලීම් අතර එය බෙදා ගැනේ සියලු සැසිවල .
• මෙම HttpSessionතාක් කල් සේවාලාභියා එම බ්රවුසරය උදාහරණයක් සමග වෙබ් යෙදුම සමඟ අනොන්ය කර තිබේ නම්, එම සැසිය සේවාදායකය පැත්තේ කල් ඉකුත් නැති ලෙස සඳහා ජීවිත. හි ඇති සියලුම ඉල්ලීම් අතර එය බෙදා ගැනේඑකම සැසියේ ගැනේ.
• මෙම HttpServletRequestසහ HttpServletResponseසම්පූර්ණ ප්රතිචාර (වෙබ් පිටුව) පැමිණ තිබේ තෙක් servlet, ග්රාහක සිට විසින් HTTP ඉල්ලීමක් ලැබෙන කාලයේ සිට සජීවී. එය එසේ නොවේ වෙනත් තැන්වල ගත්හ.
• සියල්ල Servlet, Filterසහ Listenerසිද්ධීන් වෙබ් යෙදුම ජීවත්වන තාක් කල් ජීවත් වේ. සියලුම සැසිවල සියලුම ඉල්ලීම් අතර ඒවා බෙදා ගැනේ.
• attributeඅර්ථ දක්වා ඇති ඕනෑම දෙයක් ServletContext, HttpServletRequestසහ HttpSessionප්‍රශ්නයේ ඇති වස්තුව ජීවත්වන තාක් කල් ජීවත් වේ. ජේඑස්එෆ්, සීඩීඅයි, ස්ප්‍රිං වැනි බෝංචි කළමනාකරණ රාමුවල ඇති “විෂය පථය” මෙම වස්තුවෙන් නිරූපණය වේ. එම රාමු ඒවායේ විෂය පථය බෝංචි ලෙස ගබඩා කරයිattribute වේ.

නූල් ආරක්ෂාව

එයින් කියැවෙන්නේ, ඔබේ ප්‍රධාන අවධානය යොමු විය හැක්කේ නූල් ආරක්ෂාවයි . සියලුම ඉල්ලීම් අතර සේවාදායක සහ පෙරහන් බෙදාගෙන ඇති බව ඔබ දැන් දැන සිටිය යුතුය. ජාවා පිළිබඳ හොඳ දෙය එයයි, එය බහු-නූල් සහ විවිධ නූල් (කියවන්න: HTTP ඉල්ලීම්) එකම අවස්ථාව භාවිතා කළ හැකිය. එය ප්‍රතිනිර්මාණය කිරීමට තරම් මිල අධික වනු ඇත, init()සහdestroy() ඒවා සෑම ඉල්ලීමක් සඳහාම වේ.

සර්වට්ලට් හෝ ෆිල්ටරයේ නිදර්ශන විචල්‍යයක් ලෙස ඔබ කිසි විටෙකත් කිසිදු ඉල්ලීමක් හෝ සැසියක් පරික්ෂා කළ දත්ත ලබා නොදිය යුතු බව ඔබ වටහා ගත යුතුය . එය අනෙකුත් සැසිවල අනෙකුත් සියලුම ඉල්ලීම් අතර බෙදා ගනු ඇත. බව ය නොවන නූල්-ආරක්ෂිත! පහත උදාහරණයෙන් මෙය පැහැදිලි වේ:

public class ExampleServlet extends HttpServlet {

    private Object thisIsNOTThreadSafe;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Object thisIsThreadSafe;

        thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests!
        thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe.
    } 
}

මෙයද බලන්න:

• JSF, Servlet සහ JSP අතර වෙනස කුමක්ද?
• ජාවා හි සැසි කළමනාකරණය සඳහා හොඳම විකල්පය
• සේවාදායක සිතියම්කරණ url රටාවේ / සහ / * අතර වෙනස
• සර්වට්ලට් වල doGet සහ doPost
• සර්වට්ලට් සමගාමී බ්රවුසර ඉල්ලීම් කිහිපයක් සමකාලීනව හසුරුවන බව පෙනේ
• සර්වට්ලට් නූල් ආරක්ෂිත නොවන්නේ ඇයි?

සැසිවාර

කෙටියෙන් කිවහොත්: වෙබ් සේවාදායකයා ඔහුගේ පළමු සංචාරයේ දී සෑම අමුත්තෙකුටම අද්විතීය හඳුනාගැනීමක් නිකුත් කරයි . ඊළඟ වතාවේ ඔහු හඳුනා ගැනීම සඳහා අමුත්තා එම හැඳුනුම්පත නැවත ගෙන ආ යුතුය. මෙම හදුනාගැනීමෙන් සේවාදායකයාට එක් සැසියකට අයත් වස්තු නිසි ලෙස වෙන් කිරීමට ඉඩ දෙයි.

සේවා ස්ථාපනය

නම් බර-on-ආරම්භක වේ බොරු :

නම් බර-on-ආරම්භක වේ සැබෑ :

ඔහු සේවා මාදිලියේ සහ වලක් වූ පසු, අනෙක් සියලුම සේවාදායකයින්ගේ ඉල්ලීම් මත එකම සේවාදායකය ක්‍රියා කරයි.

එක් සේවාදායකයෙකුට එක් අවස්ථාවක් තිබීම හොඳ අදහසක් නොවන්නේ ඇයි? මේ ගැන සිතා බලන්න: පැමිණි සෑම ඇණවුමක් සඳහාම ඔබ එක් පීසා කොල්ලෙකු කුලියට ගන්නවාද? එය කරන්න, ඔබ කිසි විටෙකත් ව්‍යාපාරයෙන් බැහැර වනු ඇත.

එය කුඩා අවදානමක් ඇතත්. මතක තබා ගන්න: මෙම තනි පුද්ගලයා සිය සාක්කුවේ ඇති සියලුම ඇණවුම් තොරතුරු රඳවා තබා ගනී: එබැවින් ඔබ සර්වට්ලට් වල නූල් ආරක්ෂාව ගැන සැලකිලිමත් නොවන්නේ නම් , ඔහු යම් සේවාදායකයෙකුට වැරදි ඇණවුමක් ලබා දීම අවසන් කළ හැකිය.

ජාවා සේවාදායකයේ සැසිය PHP වැනි වෙනත් භාෂාවල සැසිවාරයට සමාන වේ. එය පරිශීලකයාට සුවිශේෂී වේ. සේවාදායකයාට කුකීස්, යූආර්එල් නැවත ලිවීම වැනි විවිධ ආකාරවලින් එය නිරීක්ෂණය කළ හැකිය. මෙම ජාවා ලේඛනය ජාවා සර්වට්ලට්ස් සන්දර්භය තුළ එය පැහැදිලි කරන අතර සැසිය පවත්වා ගෙන යන්නේ කෙසේද යන්න සේවාදායකයේ නිර්මාණකරුවන්ට ඉතිරිව ඇති විස්තරයකි. පිරිවිතරයේ සඳහන් වන්නේ එය සේවාදායකයට බහුවිධ සම්බන්ධතා හරහා පරිශීලකයෙකුට අද්විතීය ලෙස පවත්වා ගත යුතු බවයි. ඔබගේ ප්‍රශ්න දෙකම පිළිබඳ වැඩි විස්තර සඳහා ඔරකල් වෙතින් මෙම ලිපිය බලන්න .

සංස්කරණය කරන්න සර්වට්ලට් තුළ සැසිය සමඟ වැඩ කරන්නේ කෙසේද යන්න පිළිබඳ විශිෂ්ට නිබන්ධනයක් මෙහි ඇත. හා මෙහි තමන් කරන්නේ කුමක්ද ජාවා Servlets සහ ඔවුන් භාවිතා කරන ආකාරය ගැන සූර්යයාගේ සිට පරිච්ඡේදයක් වේ. එම ලිපි දෙක අතර, ඔබගේ සියලු ප්‍රශ්නවලට පිළිතුරු දීමට ඔබට හැකි විය යුතුය.

සර්වට් බහාලුම (අපාචේ ටොම්කාට් වැනි) ආරම්භ වූ විට, එය කිසියම් වැරැද්දක් සිදුවුවහොත් හෝ බහාලුම් පැත්තේ කොන්සෝලයේ දෝෂයක් පෙන්නුම් කරන්නේ නම් එය වෙබ්.එක්එම්එල් ගොනුවෙන් කියවනු ඇත (යෙදුමකට එකක් පමණි), එසේ නොමැති නම්, එය සියලු වෙබ් අඩවි යෙදවීම සහ පූරණය කරනු ඇත. web.xml භාවිතා කරමින් යෙදුම් (එබැවින් එය යෙදවීමේ විස්තරය ලෙස නම් කර ඇත).

සේවාදායකයේ ක්ෂණික අවධියේදී, සර්වට්ලෙට් නිදසුන සුදානම් නමුත් සේවාදායකයාගේ ඉල්ලීමට එය සේවය කළ නොහැක, මන්ද එය තොරතුරු කොටස් දෙකක් නොමැති නිසා:
1: සන්දර්භය තොරතුරු
2: ආරම්භක වින්‍යාස තොරතුරු

සර්වට් එන්ජිම මඟින් සර්වට්ලෙට් කොන්ෆිග් අතුරුමුහුණත් වස්තුවක් නිර්මාණය කර ඇති අතර ඉහත සඳහන් තොරතුරු එහි ඇතුළත් කර ඇත. Init () සම්පුර්ණයෙන්ම ක්‍රියාත්මක වූ පසු සේවාදායකයාගේ ඉල්ලීම ඉටු කිරීමට සේවාදායකය සූදානම්.

Q) සේවා කාලය තුළ කොපමණ වාර ගණනක් ක්ෂණිකව හා ආරම්භ කිරීම සිදු වේ ද ??

අ) එක් වරක් පමණක් (සෑම සේවාදායක ඉල්ලීමක් සඳහාම නව නූලක් සාදනු ලැබේ) සේවාදායකයේ එක් අවස්ථාවක් පමණක් සේවාදායක ඉල්ලීම් ගණනට සේවය කරයි, එනම් එක් සේවාදායක ඉල්ලීම් සේවාදායකයක් සේවය කිරීමෙන් පසු මිය නොයයි. එය වෙනත් සේවාදායක ඉල්ලීම් සඳහා බලා සිටී, එනම් CGI (සෑම සේවාදායකයෙකුටම නව ක්‍රියාවලියක් නිර්මාණය කිරීම සඳහා) සේවාදායකය සමඟ සීමාව ඉක්මවා යයි (අභ්‍යන්තරව සේවාදායක එන්ජිම නූල් නිර්මාණය කරයි).

Q) සැසි සංකල්පය ක්‍රියාත්මක වන්නේ කෙසේද?

අ) getSession () HttpServletRequest වස්තුව මත කැඳවන සෑම අවස්ථාවකම

පියවර 1 : පැමිණෙන සැසි හැඳුනුම්පත සඳහා ඉල්ලීම් වස්තුව ඇගයීමට ලක් කෙරේ.

පියවර 2 : හැඳුනුම්පත නොමැති නම් අළුත් HttpSession වස්තුවක් නිර්මාණය කර එයට අනුරූප සැසි හැඳුනුම්පත ජනනය කරනු ලැබේ (එනම් හැෂ් ටේබල්) සැසි හැඳුනුම්පත httpservlet ප්‍රතිචාර වස්තුව තුළ ගබඩා කර ඇති අතර HttpSession වස්තුව පිළිබඳ සඳහන නැවත සේවාදායකයට (doGet / doPost) යවනු ලැබේ. .

පියවර 3 : හැඳුනුම්පත ලබා ගත හැකි නම් අළුත් සැසි වස්තුවක් සාදනු නොලැබේ නම්, සැසි හැඳුනුම්පත යතුර ලෙස ලබාගෙන සැසි එකතු කිරීමේදී සැසි හැඳුනුම්පත ලබා ගනී.

සෙවීම සාර්ථක වූ පසු සැසි හැඳුනුම්පත HttpServletResponse වෙත ගබඩා කර ඇති අතර පවතින සැසි වස්තු යොමු පරිශීලක ඩෙෆිනයිසර්වෙලෙට් හි doGet () හෝ doPost () වෙත යවනු ලැබේ.

සටහන:

1) සර්වට් කේතයේ සිට සේවාදායකයා වෙත පාලක කොළ පිටවන විට සැසි වස්තුව සර්වට් බහාලුම් මගින් රඳවාගෙන ඇති බව අමතක නොකරන්න.

2) බහු තෙරපීම ක්‍රියාත්මක කිරීම සඳහා සර්වට්ලට් සංවර්ධකයින්ට ඉතිරි වේ, එනම්, සේවාදායකයාගේ බහුවිධ ඉල්ලීම් හසුරුවන්න

ආරම්භක ආකෘතිය:

යෙදුම ආරම්භ වන විට (එය සේවාදායක බහාලුම මත යොදවා ඇත) හෝ එය ප්‍රථම වරට ප්‍රවේශ වූ විට (ආරම්භක ආරම්භක සැකසුම මත පදනම්ව) සේවාදායකය ක්ෂණිකව ක්‍රියාත්මක වන විට, සේවාදායකයේ ආරම්භක () ක්‍රමය හැඳින්වේ. එවිට සර්වට්ලට් (එහි එකම හා එකම අවස්ථාව) සියළුම ඉල්ලීම් (එහි සේවා () ක්‍රමය බහු නූල් මගින් කැඳවනු ලැබේ) හසුරුවයි. ඒ තුළ කිසිදු සමමුහුර්තතාවයක් තිබීම සුදුසු නොවන අතර, යෙදුම ක්‍රියාත්මක නොවූ විට (සේවාදායකයේ බහාලුම නතර වේ) සේවාදායකයේ විචල්‍යයන් වළක්වා ගත යුතුය.

සැසිවාර - ක්‍රිස් තොම්සන් පැවසූ දේ.

ස්ථාපනය කිරීම - සේවාදායකයට සිතියම් ගත කළ පළමු ඉල්ලීම කන්ටේනරයට ලැබුණු විට (සේවාදායකයේ <load-on-startup>මූලද්‍රව්‍යය සමඟ ආරම්භයේදී පැටවීම සඳහා සේවාදායකය වින්‍යාස කර නොමැති නම් web.xml). පසුකාලීන ඉල්ලීම් ඉටු කිරීම සඳහා එකම අවස්ථාව භාවිතා කරයි.

සේවා පිරිවිතර JSR-315 සේවාවේ වෙබ් බහාලුම් හැසිරීම පැහැදිලිව නිර්වචනය කරයි (සහ doGet, doPost, doPut ආදිය) ක්‍රම (2.3.3.1 බහු කියවීම් ගැටළු, පිටුව 9):

සර්වට් බහාලුමක් සර්වට්ලට් හි සේවා ක්‍රමය හරහා සමගාමී ඉල්ලීම් යැවිය හැකිය. ඉල්ලීම් හැසිරවීම සඳහා, සේවා ක්‍රමයේ බහු නූල් සමඟ සමගාමී සැකසුම් සඳහා සර්වට්ලෙට් සංවර්ධකයා ප්‍රමාණවත් ප්‍රතිපාදන සැපයිය යුතුය.

එය නිර්දේශ කර නොතිබුණද, සංවර්ධකයාට විකල්පයක් වන්නේ සේවා ක්‍රමයේදී වරකට එක් ඉල්ලීම් නූල් එකක් පමණක් ඇති බවට කන්ටේනරය සහතික කිරීම සඳහා අවශ්‍ය වන SingleThreadModel අතුරුමුහුණත ක්‍රියාත්මක කිරීමයි. සර්වට්ලට් බහාලුමක් සර්වට්ලට් එකක ඉල්ලීම් අනුක්‍රමික කිරීමෙන් හෝ සර්වට්ලට් සංචිතයක් පවත්වා ගැනීමෙන් මෙම අවශ්‍යතාව සපුරාලිය හැකිය. සේවාදායකය බෙදා හැරිය හැකි යැයි සලකුණු කර ඇති වෙබ් යෙදුමක කොටසක් නම්, කන්ටේනරය මඟින් සෑම ජේවීඑම් එකකම සේවාදායක බෙදාහැරීමේ සංචිතයක් නඩත්තු කළ හැකිය.

SingleThreadModel අතුරුමුහුණත ක්‍රියාත්මක නොකරන සේවාදායකයින් සඳහා, සේවා ක්‍රමය (හෝ HttpServlet වියුක්ත පන්තියේ සේවා ක්‍රමයට යවන doGet හෝ doPost වැනි ක්‍රම) සමමුහුර්ත යතුරුපදය සමඟ අර්ථ දක්වා තිබේ නම්, සේවාදායක බහාලුමට නිදර්ශන සංචිත ප්‍රවේශය භාවිතා කළ නොහැක. , නමුත් ඒ හරහා ඉල්ලීම් අනුක්‍රමික කළ යුතුය. කාර්ය සාධනයට අහිතකර බලපෑම් හේතුවෙන් සංවර්ධකයින් මෙම තත්වයන් තුළ සේවා ක්‍රමය (හෝ ඒ වෙත යවන ලද ක්‍රම) සමමුහුර්ත නොකරන ලෙස තරයේ නිර්දේශ කෙරේ.

ඉහත පැහැදිලි කිරීම් වලින් පැහැදිලි වන පරිදි, SingleThreadModel ක්‍රියාත්මක කිරීමෙන්, සර්වට්ලට් බහාලුම් මඟින් නූල්-ආරක්ෂාව සහතික කළ හැකිය. බහාලුම් ක්‍රියාත්මක කිරීමෙන් මෙය ක්‍රම 2 කින් කළ හැකිය:

1) ඉල්ලීම් අනුක්‍රමික කිරීම (පෝලිම්) තනි අවස්ථාවකට - මෙය සිංගල් ට්‍රෙඩ් මොඩලය ක්‍රියාත්මක නොකරන සර්වට්ලට් එකකට සමානය, නමුත් සේවා / ඩොක්ස්එක්ස් ක්‍රම සමමුහුර්ත කිරීම; හෝ

2) අවස්ථා සංචිතයක් නිර්මාණය කිරීම - එය වඩා හොඳ විකල්පයක් වන අතර එය සේවාදායකයේ ආරම්භක / ආරම්භක උත්සාහය / වේලාව අතර හුවමාරුවකි.

අංක Servlets ඇත ආරක්ෂිත නූල් නෑ

මෙය වරකට නූල් එකකට වඩා ප්‍රවේශ වීමට ඉඩ දෙයි

ඔබට එය ත්‍රෙඩ් ආරක්ෂිත ලෙස සර්වට්ලට් කිරීමට අවශ්‍ය නම්, යූ සඳහා යා හැකිය

Implement SingleThreadInterface(i) එය හිස් අතුරුමුහුණතක් නැත

ක්‍රම

නැතහොත් අපට සමමුහුර්ත ක්‍රම සඳහා යා හැකිය

සමමුහුර්තකරණය භාවිතා කිරීමෙන් අපට සම්පූර්ණ සේවා ක්‍රමය සමමුහුර්ත කළ හැකිය

ක්‍රමය ඉදිරිපිට යතුරු පදය

උදාහරණයක්::

public Synchronized class service(ServletRequest request,ServletResponse response)throws ServletException,IOException

හෝ අපට සමමුහුර්ත කොටසේ කේතය දැමිය හැකිය

උදාහරණයක්::

Synchronized(Object)

{

----Instructions-----

}

සමස්ථ ක්‍රමවේදය සෑදීමට වඩා සමමුහුර්ත බ්ලොක් වඩා හොඳ යැයි මට හැඟේ

සමමුහුර්ත