সার্লেলেটগুলি কীভাবে কাজ করবে? ইনস্ট্যান্টেশন, সেশনস, ভাগ করা ভেরিয়েবল এবং মাল্টিথ্রেডিং


1142

মনে করুন, আমার কাছে একটি ওয়েবসারভার রয়েছে যা অসংখ্য সার্লেটলেট ধারণ করে। এই সার্লেটগুলির মধ্যে পাস করার তথ্যের জন্য আমি সেশন এবং উদাহরণের ভেরিয়েবল সেট করছি।

এখন, যদি 2 বা আরও বেশি ব্যবহারকারী এই সার্ভারে অনুরোধ প্রেরণ করেন তবে সেশন ভেরিয়েবলগুলির কী হবে?
এগুলি কি সমস্ত ব্যবহারকারীর জন্য সাধারণ হবে বা প্রতিটি ব্যবহারকারীর জন্য তারা আলাদা হবে?
যদি সেগুলি আলাদা হয়, তবে সার্ভারটি কীভাবে বিভিন্ন ব্যবহারকারীর মধ্যে পার্থক্য করতে সক্ষম হয়েছিল?

আরও একটি অনুরূপ প্রশ্ন, যদি nকোনও নির্দিষ্ট সার্লেটকে ব্যবহারকারীরা অ্যাক্সেস করে থাকে, তবে এই সার্লেটটি কেবল প্রথমবার প্রথম ব্যবহারকারী অ্যাক্সেস করলে বা এটি পৃথকভাবে সমস্ত ব্যবহারকারীর জন্য ইনস্ট্যান্ট হয়?
অন্য কথায়, উদাহরণের ভেরিয়েবলগুলির সাথে কী ঘটে?

উত্তর:


1820

ServletContext

যখন সার্লেট পাত্রে ( অ্যাপাচি টমক্যাটের মতো ) শুরু হবে, এটি তার সমস্ত ওয়েব অ্যাপ্লিকেশন স্থাপন এবং লোড করবে। যখন কোনও ওয়েব অ্যাপ্লিকেশন লোড হয়, সার্ভলেট ধারকটি 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 ম হয়, 2দ্বিতীয় হয়, ইত্যাদি)। একই মান একাধিক সার্ভলেট জন্য নির্দিষ্ট করা থাকে, তাহলে সেই সার্ভলেট প্রতিটি একই আদেশ লোড হয় হিসাবে তারা প্রদর্শিত web.xml, web-fragment.xmlবা @WebServletclassloading। ইভেন্টটিতে "লোড-অন-স্টার্টআপ" মানটি অনুপস্থিত থাকলে, init()যখনই এইচটিটিপি অনুরোধটি প্রথমবারের জন্য সেই সার্লেটটিকে হিট করে তখনই পদ্ধতিটি চালু করা হবে।

উপরোক্ত বর্ণিত সমস্ত সূচনা পদক্ষেপের সাথে সার্ভলেট ধারক শেষ হয়ে গেলে, তখনই অনুরোধ করা ServletContextListener#contextInitialized()হবে।

যখন নিচে সার্ভলেট ধারক স্থবির, এটা সমস্ত ওয়েব অ্যাপ্লিকেশনের unloads, ডাকে destroy()তার সকল সক্রিয়া সার্ভলেট এবং ফিল্টার, এবং সমস্ত পদ্ধতি ServletContext, Servlet, Filterএবং Listenerদৃষ্টান্ত ট্র্যাশ করছে। শেষ পর্যন্ত ServletContextListener#contextDestroyed()প্রার্থনা করা হবে।

এইচটিটিপি সার্ভলেটআরকোয়েস্ট এবং এইচটিটিপি সার্ভেলিটেস্পোনস

সার্ভলেট ধারকটি একটি ওয়েব সার্ভারের সাথে সংযুক্ত রয়েছে যা একটি নির্দিষ্ট পোর্ট নম্বরে HTTP অনুরোধের জন্য শোনায় (পোর্ট 8080 সাধারণত বিকাশের সময় ব্যবহৃত হয় এবং 80 বন্দর উত্পাদন হয়)। যখন কোনও ক্লায়েন্ট (যেমন কোনও ওয়েব ব্রাউজার সহ ব্যবহারকারী বা প্রোগ্রামক্রমে ব্যবহার করেURLConnection ) কোনও এইচটিটিপি অনুরোধ প্রেরণ করে , সার্লেলেট ধারকটি নতুন HttpServletRequestএবং HttpServletResponseঅবজেক্ট তৈরি করে এবং Filterচেইনে সংজ্ঞায়িত যে কোনও মাধ্যমে এবং শেষ পর্যন্ত Servletউদাহরণটি দিয়ে যায়।

ফিল্টারগুলির ক্ষেত্রে , doFilter()পদ্ধতিটি চাওয়া হয়। সার্ভলেট ধারকের কোড কল chain.doFilter(request, response)করার সময়, পরবর্তী ফিল্টারটিতে অনুরোধ এবং প্রতিক্রিয়া অবিরত থাকে, বা যদি কোনও ফিল্টার না থাকে তবে সার্লেটকে চাপুন।

সার্লেলেটের ক্ষেত্রে , service()পদ্ধতিটি চাওয়া হয়। ডিফল্টরূপে, এই পদ্ধতিটি নির্ধারণ করে যে doXxx()পদ্ধতিগুলির মধ্যে কোনটির ভিত্তিতে অফ করা উচিত request.getMethod()। যদি নির্ধারিত পদ্ধতি সার্ভলেট থেকে অনুপস্থিত থাকে তবে প্রতিক্রিয়াতে একটি HTTP 405 ত্রুটি ফিরে আসে।

অনুরোধের অবজেক্টটি এইচটিটিপি অনুরোধ সম্পর্কিত সমস্ত তথ্যের অ্যাক্সেস সরবরাহ করে যেমন এর ইউআরএল, শিরোনাম, ক্যোয়ারী স্ট্রিং এবং বডি। প্রতিক্রিয়া অবজেক্টটি HTTP প্রতিক্রিয়াটি আপনি যেভাবে চান তা নিয়ন্ত্রণ এবং প্রেরণ করার ক্ষমতা সরবরাহ করে, উদাহরণস্বরূপ, আপনাকে শিরোনাম এবং বডি সেট করতে দেয় (সাধারণত কোনও জেএসপি ফাইল থেকে উত্পন্ন এইচটিএমএল সামগ্রী সহ)। যখন HTTP প্রতিক্রিয়া প্রতিশ্রুতিবদ্ধ এবং সমাপ্ত হয়, অনুরোধ এবং প্রতিক্রিয়া দুটিই পুনর্ব্যবহারযোগ্য এবং পুনরায় ব্যবহারের জন্য উপলব্ধ করা হয়।

HttpSession

যখন কোনও ক্লায়েন্ট প্রথমবার ওয়েবপৃষ্ঠায় যান এবং / অথবা এটি HttpSessionপ্রথমবারের মাধ্যমে পাওয়া যায় request.getSession(), সার্লেলেট ধারক একটি নতুন HttpSessionঅবজেক্ট তৈরি করে, একটি দীর্ঘ এবং অনন্য আইডি তৈরি করে (যা আপনি পেতে পারেন session.getId()) এবং এটি সার্ভারের মধ্যে সংরক্ষণ করে স্মৃতি. সার্ভলেট ধারক একটি সেট করে CookieSet-Cookieসঙ্গে HTTP প্রতিক্রিয়া শিরোলেখ JSESSIONIDতার নাম এবং তার মান হিসাবে অনন্য সেশন আইডি হিসেবে।

অনুযায়ী HTTP- র কুকি স্পেসিফিকেশন (ক চুক্তি কোন ভদ্র ওয়েব ব্রাউজার এবং ওয়েব সার্ভার মেনে চলতে হবে), ক্লায়েন্ট (ওয়েব ব্রাউজার) এই কুকিতে পরবর্তী অনুরোধগুলিতে ফেরত পাঠাতে প্রয়োজন বোধ করা হয় Cookieযতদিন কুকি বৈধ হেডারের ( অর্থাত্ ইউনিক আইডি অবশ্যই একটি অপ্রয়োজনীয় সেশনের উল্লেখ করতে হবে এবং ডোমেন এবং পথটি সঠিক)। আপনার ব্রাউজারের অন্তর্নির্মিত HTTP ট্র্যাফিক মনিটর ব্যবহার করে, আপনি কুকিটি বৈধ কিনা তা যাচাই করতে পারেন (Chrome / ফায়ারফক্স 23+ / আই 9 + এ F12 টিপুন এবং নেট / নেটওয়ার্ক ট্যাবটি পরীক্ষা করুন )। সার্লেটের কন্টেইনারটি Cookieনাম সহ কুকির উপস্থিতির জন্য প্রতিটি আগত এইচটিটিপি অনুরোধের শিরোনামটি পরীক্ষা করবে JSESSIONIDএবং HttpSessionসার্ভারের স্মৃতি থেকে যুক্ত হওয়ার জন্য এর মান (সেশন আইডি) ব্যবহার করবে ।

HttpSessionথাকার বিষয়টি মতেই এটা না হওয়া পর্যন্ত জীবিত উল্লেখিত সময়সীমার মান বেশি অলস হয়েছে (যেমন একটি অনুরোধে ব্যবহৃত নয়) <session-timeout>, কোন সেটিংস web.xml। সময়সীমা মান 30 মিনিটের ডিফল্ট হয়। সুতরাং, যখন ক্লায়েন্ট নির্দিষ্ট সময়ের চেয়ে বেশি সময় ধরে ওয়েব অ্যাপটিতে যান না, সার্লেট ধারকটি সেশনটি ট্র্যাশ করে। পরবর্তী প্রতিটি অনুরোধ, এমনকি কুকি নির্দিষ্ট করে দেওয়া থাকলেও একই অধিবেশনটিতে আর অ্যাক্সেস থাকবে না; সার্লেট ধারক একটি নতুন সেশন তৈরি করবে।

ক্লায়েন্টের পক্ষে, সেশন কুকি যতক্ষণ ব্রাউজারের দৃষ্টান্তটি চলবে ততক্ষণ বেঁচে থাকে। সুতরাং, যদি ক্লায়েন্ট ব্রাউজারের উদাহরণটি বন্ধ করে দেয় (সমস্ত ট্যাব / উইন্ডো), তবে সেশনটি ক্লায়েন্টের পাশে ট্র্যাস করা হবে। নতুন ব্রাউজারের উদাহরণে, সেশনের সাথে সম্পর্কিত কুকির অস্তিত্ব থাকবে না, সুতরাং এটি আর প্রেরণ করা হবে না। এটি HttpSessionসম্পূর্ণ নতুন সেশন কুকি ব্যবহারের সাথে সম্পূর্ণ নতুন তৈরি হওয়ার কারণ ঘটায় ।

সংক্ষেপে

  • ServletContextযতদিন ওয়েব অ্যাপ্লিকেশন জীবন যেমন জন্য বেঁচে আছেন। এটি সমস্ত সেশনে সমস্ত অনুরোধগুলির মধ্যে ভাগ করা হয় ।
  • HttpSessionযতদিন ক্লায়েন্ট একই ব্রাউজারে নিদর্শনের সঙ্গে ওয়েব অ্যাপ্লিকেশন সাথে আলাপচারিতার হয়, এবং অধিবেশন সার্ভার সাইড এ সময় শেষ হয়েছে করেননি জন্য বেঁচে আছেন। এটি একই সেশনে সমস্ত অনুরোধগুলির মধ্যে ভাগ করা হয় ।
  • HttpServletRequestএবং HttpServletResponse, সময় সার্ভলেট ক্লায়েন্ট থেকে একটি HTTP অনুরোধ গ্রহণ করে থেকে লাইভ পর্যন্ত সম্পূর্ণ প্রতিক্রিয়া (ওয়েব পৃষ্ঠা) এসেছে। এটি অন্য কোথাও ভাগ করে নেওয়া হয় না
  • সমস্ত Servlet, Filterএবং Listenerদৃষ্টান্তগুলি যতক্ষণ না ওয়েব অ্যাপ্লিকেশন বেঁচে থাকে। তারা সমস্ত সেশনে সমস্ত অনুরোধের মধ্যে ভাগ করা হয় ।
  • কোন attributeযে সংজ্ঞায়িত করা হয় ServletContext, HttpServletRequestএবং HttpSessionপ্রশ্ন জীবনে অবজেক্ট হিসেবে যতদিন বেঁচে থাকবে। জেএসএফ, সিডিআই, স্প্রিং ইত্যাদির মতো শিম ম্যানেজমেন্ট ফ্রেমওয়ার্কগুলিতে অবজেক্টটি নিজেই "স্কোপ" উপস্থাপন করে Those ফ্রেমওয়ার্কগুলি তাদের স্কোপযুক্ত মটরশুটিটিকে attributeতার নিকটতম মিলের সুযোগ হিসাবে সংরক্ষণ করে store

থ্রেড সুরক্ষা

এটি বলেছিল, আপনার বড় উদ্বেগ সম্ভবত সুরক্ষা থ্রেড । আপনার এখন জানা উচিত যে সার্ভলেট এবং ফিল্টারগুলি সমস্ত অনুরোধের মধ্যে ভাগ করা আছে। এটি জাভা সম্পর্কে দুর্দান্ত জিনিস, এটি মাল্টিথ্রেডেড এবং বিভিন্ন থ্রেড (পড়ুন: 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.
    } 
}

আরো দেখুন:


25
সুতরাং আমি যখন কোনও উপায়ে জেএসশনআইডিটি জানতে পারি যা কোনও ক্লায়েন্টকে প্রেরণ করে, আমি তার সেশনটি চুরি করতে পারি?
তোসকান

54
@ তোসকান: এটি সঠিক। এটি সেশন ফিক্সেশন হ্যাক হিসাবে পরিচিত । দয়া করে মনে রাখবেন যে এটি জেএসপি / সার্লেটের সাথে নির্দিষ্ট নয়। কুকি দ্বারা সেশন বজায় রাখে এমন অন্যান্য সমস্ত সার্ভার সাইড ল্যাঙ্গুয়েজগুলিও সংবেদনশীল, যেমন PHPSESSIDকুকির সাথে পিএইচপি, কুকি সহ ASP.NET_SessionIDএএসপি.এনইটি, ইত্যাদি ইত্যাদি ra এজন্য ;jsessionid=xxxকিছু জেএসপি / সার্ভলেট এমভিসি ফ্রেমওয়ার্ক স্বয়ংক্রিয়ভাবে করা হিসাবে ইউআরএল পুনর্লিখনকে অস্বীকার করা হয়। কেবল নিশ্চিত হয়ে নিন যে সেশন আইডি কখনই ইউআরএলে বা ওয়েবপৃষ্ঠায় অন্য কোনও উপায়ে উন্মুক্ত না হয় যাতে অজানা এন্ডুসারকে আক্রমণ করা না যায়।
BalusC

11
@ তোসকান: এছাড়াও, আপনার ওয়েব অ্যাপস এক্সএসএস আক্রমণে সংবেদনশীল না তা নিশ্চিত করুন। অর্থাৎ অনস্কেপড ফর্মটিতে কোনও ব্যবহারকারী-নিয়ন্ত্রিত ইনপুট পুনরায় খেলুন না। এক্সএসএস সকল এন্ডেজেসারদের সেশন আইডি সংগ্রহের জন্য দরজা উন্মুক্ত করে দেয়। আরও দেখুন এক্সএসএসের পিছনে সাধারণ ধারণাটি কী?
BalusC

2
@ বালুসসি, আমার বোকামির জন্য দুঃখিত। এর অর্থ সমস্ত ব্যবহারকারী এই আইএনএনটিথ্রেডসেফের একই উদাহরণে অ্যাক্সেস করতে পারে?
ছায়াচ্ছন্ন

4
সম্পূর্ণ সার্লেট নিজেই অনুপস্থিত থাকলে @ টুথম্বস্টিক্স 404 এ ফিরে আসবে সার্লেটলেট উপস্থিত থাকলে 405 ফেরত দেওয়া হয় তবে কাঙ্ক্ষিত ডোএক্সএক্সএক্সএক্স () পদ্ধতি প্রয়োগ করা হয় না।
বালাসসি

428

দায়রা

এখানে চিত্র বর্ণনা লিখুন এখানে চিত্র বর্ণনা লিখুন

সংক্ষেপে: ওয়েব সার্ভার তার প্রথম দর্শনে প্রতিটি দর্শনার্থীর জন্য একটি অনন্য সনাক্তকারী জারি করে । তার পরের বারের মতো স্বীকৃতি পাওয়ার জন্য দর্শনার্থীকে অবশ্যই সেই আইডি ফিরিয়ে আনতে হবে। এই শনাক্তকারীটি সার্ভারকে অন্য সেশনের বিপরীতে এক সেশনের মালিকানাধীন অবজেক্টগুলিকে যথাযথভাবে পৃথক করার অনুমতি দেয়।

সার্লেট ইনস্ট্যান্টেশন

যদি লোড অন সূচনার হয় মিথ্যা :

এখানে চিত্র বর্ণনা লিখুন এখানে চিত্র বর্ণনা লিখুন

যদি লোড অন সূচনার হয় সত্য :

এখানে চিত্র বর্ণনা লিখুন এখানে চিত্র বর্ণনা লিখুন

একবার সে পরিষেবা মোডে এবং খাঁজে উঠলে , একই সার্লেটটি অন্য সমস্ত ক্লায়েন্টের অনুরোধের ভিত্তিতে কাজ করবে।

এখানে চিত্র বর্ণনা লিখুন

প্রতি ক্লায়েন্টের জন্য একটি উদাহরণ থাকা ভাল ধারণা নয় কেন? এ সম্পর্কে ভাবুন: প্রতিবারের আদেশের জন্য আপনি কি একটি পিজ্জা লোক ভাড়া করবেন? এটি করুন এবং আপনি কোনও দিনেই ব্যবসায়ের বাইরে চলে যাবেন।

এটি যদিও একটি ছোট ঝুঁকি নিয়ে আসে। মনে রাখবেন: এই একক লোকটি তার পকেটে সমস্ত অর্ডার সংক্রান্ত তথ্য রাখে: সুতরাং যদি আপনি সার্লেটগুলিতে থ্রেড সুরক্ষা সম্পর্কে সতর্ক হন না , তবে তিনি কোনও নির্দিষ্ট ক্লায়েন্টকে ভুল অর্ডার দিয়ে শেষ করতে পারেন।


26
আপনার ছবিটি আমার বোধগম্যতার জন্য খুব ভাল। আমার একটি প্রশ্ন আছে, যখন অনেক পিজ্জা অর্ডার আসে তখন এই পিজ্জা রেস্তোঁরাগুলি কী করবে, কেবল একটি পিজ্জা লোকের জন্য অপেক্ষা করুন বা আরও পিজ্জা লোক ভাড়া করবেন? ধন্যবাদ
zh18

6
তিনি এই বার্তায় ফিরে to many requests at this moment. try again later
আসবেন

3
পিজা ডেলিভারি লোকেদের মতো সার্ভলেটগুলি একই সাথে একাধিক ডেলিভারি করতে পারে। তাদের কেবল ক্লায়েন্টের ঠিকানা, পিৎজার স্বাদ লিখেছে সেখানে তাদের বিশেষ যত্ন নেওয়া প্রয়োজন ...
ব্রুনো

42

জাভা সার্লেটলে সেশন পিএইচপি এর মতো অন্যান্য ভাষায় সেশনের সমান। এটি ব্যবহারকারীর কাছে অনন্য। সার্ভারটি বিভিন্ন উপায়ে যেমন কুকিজ, ইউআরএল পুনর্লিখন ইত্যাদির উপর নজর রাখতে পারে এই জাভা ডক নিবন্ধটি জাভা সার্লেটগুলির প্রসঙ্গে এটিকে ব্যাখ্যা করে এবং বোঝায় যে সেশনটি ঠিক কীভাবে বজায় রাখা হয় তা সার্ভারের ডিজাইনারদের একটি বাস্তবায়ন বিবরণ রেখে যায়। স্পেসিফিকেশনটি কেবল এই শর্ত দেয় যে এটি অবশ্যই সার্ভারের সাথে একাধিক সংযোগ জুড়ে ব্যবহারকারীর কাছে অনন্য হিসাবে বজায় রাখতে হবে। পরীক্ষা করে দেখুন ওরাকল থেকে এই নিবন্ধটি আপনার প্রশ্ন উভয় আরো তথ্যের জন্য।

সম্পাদনা এখানে সার্লেলেটের অভ্যন্তরে সেশন নিয়ে কীভাবে কাজ করা যায় সে সম্পর্কে একটি দুর্দান্ত টিউটোরিয়াল রয়েছে । এবং এখানে জাভা সার্লেটস সম্পর্কে তারা সূর্যের একটি অধ্যায়, সেগুলি কীভাবে এবং সেগুলি কীভাবে ব্যবহার করবেন সে সম্পর্কে। এই দুটি নিবন্ধের মধ্যে আপনার সমস্ত প্রশ্নের উত্তর দিতে সক্ষম হওয়া উচিত।


এটি আমার জন্য আরও একটি প্রশ্ন এনেছে, যেহেতু পুরো অ্যাপ্লিকেশনটির জন্য কেবলমাত্র একটি সার্লেট প্রসঙ্গ রয়েছে এবং আমরা এই সার্লেলেটকন্টেক্সটের মাধ্যমে সেশন ভেরিয়েবলগুলিতে অ্যাক্সেস পাই যাতে সেশন ভেরিয়েবলগুলি প্রতিটি ব্যবহারকারীর পক্ষে কীভাবে অনন্য হতে পারে? ধন্যবাদ ..
কু জোন

1
সার্ভলেট কনটেক্সট থেকে আপনি কীভাবে সেশনটি অ্যাক্সেস করছেন? আপনি servletContext.setAttribute () উল্লেখ করছেন না, আপনি কি?
ম্যাট বি

4
@ কুজোন প্রতিটি ওয়েব অ্যাপ্লিকেশনটির একটি করে ServletContextঅবজেক্ট থাকে। এই অবজেক্টটির শূন্য, এক, বা একাধিক সেশন অবজেক্ট রয়েছে - সেশন অবজেক্টের সংগ্রহ। প্রতিটি সেশনটি কোনও এক ধরণের সনাক্তকারী স্ট্রিং দ্বারা চিহ্নিত করা হয়, যেমন অন্য উত্তরে কার্টুনগুলিতে দেখা যায়। কুকি বা ইউআরএল-পুনর্লিখনের মাধ্যমে সেই শনাক্তকারীকে ক্লায়েন্টে ট্র্যাক করা হয়। প্রতিটি সেশনের অবজেক্টের নিজস্ব ভেরিয়েবল থাকে।
বেসিল বাউরক

33

সার্ভলেট ধারক (অ্যাপাচি টমক্যাটের মতো) শুরু হয়ে গেলে, ওয়েব.এক্সএমএল ফাইল থেকে পড়বে (কোনও অ্যাপ্লিকেশন কেবলমাত্র) যদি কোনও কিছু ভুল হয়ে যায় বা ধারক সাইড কনসোলে কোনও ত্রুটি দেখায়, অন্যথায়, এটি সমস্ত ওয়েব মোতায়েন এবং লোড করবে ওয়েব.এক্সএমএল ব্যবহার করে অ্যাপ্লিকেশনগুলি (তাই এটি ডিপ্লোমাইটিং বর্ণনাকারী হিসাবে নাম দেওয়া হয়েছে)।

সার্লেটের তাত্ক্ষণিক পর্যায়ে সার্ভলেট উদাহরণ প্রস্তুত থাকলেও এটি ক্লায়েন্টের অনুরোধটি পরিবেশন করতে পারে না কারণ এটি দুটি টুকরো তথ্যের সাথে অনুপস্থিত:
1: প্রসঙ্গ তথ্য
2: প্রাথমিক কনফিগারেশন তথ্য

সার্ভলেট ইঞ্জিনটি সার্লেটলেট কনফাইগ ইন্টারফেস অবজেক্ট তৈরি করে এটিতে উপরোক্ত অনুপস্থিত তথ্যের মধ্যে সার্ভলেট ইঞ্জিন কল দেয় সার্ভলেট-এর সার্ভলেট-এর কনফিগ অবজেক্ট রেফারেন্সকে আর্গুমেন্ট হিসাবে সরবরাহ করে। একবার init () পুরোপুরি কার্যকর হয়ে গেলে সার্লেট ক্লায়েন্টের অনুরোধটি পরিবেশন করতে প্রস্তুত।

প্রশ্ন) সার্লেটের জীবদ্দশায় কতবার ইনস্ট্যান্টেশন এবং আরম্ভ হয় ??

ক) কেবল একবার (প্রতিটি ক্লায়েন্টের অনুরোধের জন্য একটি নতুন থ্রেড তৈরি করা হয়েছে) সার্লেটের কেবল একটি উদাহরণ ক্লায়েন্টের অনুরোধের সংখ্যার পরিবেশন করে যেমন, একটি ক্লায়েন্ট অনুরোধ সার্ভার পরিবেশন করার পরে মারা যায় না। এটি অন্যান্য ক্লায়েন্টের অনুরোধগুলির জন্য অপেক্ষা করে, যা সিজিআই (প্রতিটি ক্লায়েন্টের অনুরোধের জন্য একটি নতুন প্রক্রিয়া তৈরি করা হয়) সার্লেটের মাধ্যমে সীমাবদ্ধতা অতিক্রম করা হয় (অভ্যন্তরীণভাবে সার্লেট ইঞ্জিনটি থ্রেড তৈরি করে)।

প্রশ্ন) সেশন কনসেপ্ট কীভাবে কাজ করে?

ক) যখনই গেটসেশন () এইচটিটিপি সার্ভেলেকোয়েস্ট অবজেক্টে কল করা হবে

পদক্ষেপ 1 : অনুরোধ অবজেক্টটি আগত সেশন আইডির জন্য মূল্যায়ন করা হয়।

পদক্ষেপ 2 : যদি আইডি না পাওয়া যায় তবে একটি নতুন এইচটিটিপিএসশন অবজেক্ট তৈরি করা হয় এবং এর সাথে সম্পর্কিত সেশন আইডি উত্পন্ন হয় (অর্থাত্ হ্যাশটবেল) সেশন আইডিটি পোস্টসারলেট প্রতিক্রিয়া অবজেক্টে সংরক্ষণ করা হয় এবং এইচটিটিপিএসশন অবজেক্টের রেফারেন্স সার্ভলেটে ফিরে আসে (ডোজেট / ডপপস্ট) ।

পদক্ষেপ 3 : আইডি উপলভ্য যদি নতুন সেশন অবজেক্টটি তৈরি না হয় তবে সেশন আইডিটি কী হিসাবে সেশন আইডি ব্যবহার করে সেশন সংগ্রহের জন্য অনুরোধের অবজেক্ট অনুসন্ধান থেকে নেওয়া হয়।

অনুসন্ধানটি সফল হয়ে যাওয়ার পরে এইচটিটিএস সার্লেটআরস্পোনসে সেশন আইডি সংরক্ষণ করা হয় এবং বিদ্যমান সেশন অবজেক্টের রেফারেন্সগুলি ইউজারডিফাইনসার্লেলেটের ডোজেট () বা ডপোস্ট () এ ফিরে আসে।

বিঃদ্রঃ:

1) সার্ভারলেট কোড থেকে ক্লায়েন্টের কাছে নিয়ন্ত্রণের পাতাগুলি ভুলে যাবেন না যে সার্ভলেট ধারক অর্থাৎ সার্লেট ইঞ্জিন দ্বারা অধিবেশনটি রাখা হচ্ছে

২) সার্টিলেট বিকাশকারীদের প্রয়োগের জন্য যেমন মাল্টিথ্রেডিং বাকি রয়েছে, ক্লায়েন্টের একাধিক অনুরোধগুলি মাল্টিথ্রিড কোড সম্পর্কে বিরক্ত করার জন্য কিছুই হ্যান্ডেল করে না

অন্তর্ভুক্ত ফর্ম:

অ্যাপ্লিকেশন শুরু হওয়ার সাথে সাথে এটি সার্ভলেট তৈরি করা হয় (এটি সার্ভলেট ধারকটিতে স্থাপন করা হয়) অথবা সার্ভলেটটি ইনস্ট্যান্ট করা অবস্থায় যখন এটি প্রথম অ্যাক্সেস করা হয় (লোড-অন-স্টার্টআপ সেটিংয়ের উপর নির্ভর করে), সার্লেটের আর (পদ্ধতি) বলা হয় তারপরে সার্লেট (এটির একমাত্র এবং একমাত্র উদাহরণ) সমস্ত অনুরোধগুলি পরিচালনা করে (এর পরিষেবা () পদ্ধতিটি একাধিক থ্রেড দ্বারা ডাকা হচ্ছে)। এ কারণেই এটিতে কোনও সুসংগতি স্থাপন করার পরামর্শ দেওয়া হয় না, এবং অ্যাপ্লিকেশনটি চাকরিবিহীন অবস্থায় (সার্লেট ধারক থামিয়ে দেওয়া হয়), ডার্ট () পদ্ধতিটি বলা হয়ে গেলে আপনার সার্লেটের উদাহরণ পরিবর্তনগুলি এড়ানো উচিত।


20

সেশনস - ক্রিস থম্পসন যা বলেছিলেন।

ইনস্ট্যান্টেশন - একটি প্যাকেজটি সার্লেটটিতে ম্যাপযুক্ত প্রথম অনুরোধটি গ্রহণ করে (সার্ভলেটটি যখন <load-on-startup>উপাদানটিতে স্টার্টআপে লোড করার জন্য কনফিগার করা না থাকে web.xml) তা ইনস্ট্যান্টেশন করা হয় । পরবর্তী অনুরোধগুলি পরিবেশন করতে একই উদাহরণ ব্যবহার করা হয়।


3
সঠিক। অতিরিক্ত চিন্তা: প্রতিটি অনুরোধটি সেই একক সার্লেটের উদাহরণে চালানোর জন্য একটি নতুন (বা পুনর্ব্যবহারযোগ্য) থ্রেড পেয়েছে। প্রতিটি সার্লেটের একটি উদাহরণ রয়েছে এবং সম্ভবত অনেকগুলি থ্রেড রয়েছে (যদি এক সাথে অনেকগুলি অনুরোধ হয়)।
তুলসী বাউরক

13

সার্ভলেট স্পেসিফিকেশন JSR-315 পরিষ্কারভাবে পরিষেবাতে ওয়েব ধারক আচরণ সংজ্ঞায়িত (এবং অবশ্যই doGet, doPost, doPut ইত্যাদি) পদ্ধতি (2.3.3.1 Multithreading সমস্যা, পৃষ্ঠা 9):

একটি সার্লেট পাত্রে সার্লেটের পরিষেবা পদ্ধতির মাধ্যমে একযোগে অনুরোধগুলি প্রেরণ করা যেতে পারে। অনুরোধগুলি পরিচালনা করতে, সার্লেট বিকাশকারীকে পরিষেবা পদ্ধতিতে একাধিক থ্রেড সহ সমবর্তী প্রক্রিয়াকরণের পর্যাপ্ত ব্যবস্থা করতে হবে।

যদিও এটি প্রস্তাবিত নয়, বিকাশকারীদের জন্য একটি বিকল্প হ'ল সিঙ্গলথ্রেডমোডেল ইন্টারফেসটি প্রয়োগ করা যা পরিষেবা পদ্ধতিতে এক সময়ে কেবল একটি অনুরোধের থ্রেডের গ্যারান্টি দেওয়ার জন্য ধারক প্রয়োজন। কোনও সার্লেটের পাত্রে কোনও সার্লেটে অনুরোধগুলি সিরিয়ালাইজ করে বা সার্লেটের উদাহরণগুলির একটি পুল বজায় রেখে এই প্রয়োজনীয়তা মেটানো যেতে পারে। সার্ভলেট যদি এমন কোনও ওয়েব অ্যাপ্লিকেশনের অংশ হয় যা বিতরণযোগ্য হিসাবে চিহ্নিত করা হয়, তবে ধারকটি প্রতিটি JVM- এ সার্ভলেট উদাহরণগুলির একটি পুল বজায় রাখতে পারে যা অ্যাপ্লিকেশন জুড়ে বিতরণ করা হয়েছে।

সিঙ্গেলথ্রেডমোডেল ইন্টারফেস বাস্তবায়ন না করা সার্ভলেটগুলির জন্য, যদি সার্ভিস পদ্ধতিটি (বা এইচটিটিপি সার্ভলেট অ্যাবস্ট্রাক্ট শ্রেণীর পরিষেবা পদ্ধতিতে প্রেরিত ডোগেট বা ডপস্টের পদ্ধতিগুলি) সিঙ্ক্রোনাইজড কীওয়ার্ড দিয়ে সংজ্ঞায়িত করা হয়, সার্লেট পাত্রে উদাহরণ পল পদ্ধতির ব্যবহার করতে পারবেন না , তবে অবশ্যই এর মাধ্যমে অনুরোধগুলিকে সিরিয়ালাইজ করতে হবে। এই পরিস্থিতিতে দৃ Develop়ভাবে সুপারিশ করা হয় যে বিকাশকারীরা এই পরিস্থিতিতে কর্মক্ষেত্রে ক্ষতিকারক প্রভাবের কারণে পরিষেবা পদ্ধতি (বা এটি প্রেরিত পদ্ধতিগুলি) সিঙ্ক্রোনাইজ না করে


2
এফওয়াইআই, বর্তমান সার্লেট স্পেক (2015-01) 3.1, জেএসআর 340 দ্বারা সংজ্ঞায়িত ।
বাসিল বাউরক


1
খুব ঝরঝরে উত্তর! @ থারিন্ডু_ডিজি
টম টেলর

0

উপরের ব্যাখ্যাগুলি থেকে স্পষ্ট যে, সিঙ্গলথ্রেডমোডেল বাস্তবায়নের মাধ্যমে সার্ভলেট ধারক দ্বারা একটি সার্লেটকে থ্রেড-সুরক্ষা দেওয়া যেতে পারে। ধারক বাস্তবায়ন এটি 2 উপায়ে করতে পারে:

1) অনুরোধগুলি ক্রিয়াকলাপ করার জন্য (সারিবদ্ধ) এক উদাহরণে - এটি সিঙ্গেলথ্রেডমোডেল বাস্তবায়ন না করে এমন একটি সার্লেটের অনুরূপ তবে পরিষেবা / ডোএক্সএক্সএক্স পদ্ধতিগুলি সিঙ্ক্রোনাইজ করছে; অথবা

২) উদাহরণস্বরূপ একটি পুল তৈরি করা - যা সার্লেটের হোস্টিং পরিবেশের সীমাবদ্ধ পরামিতিগুলির (মেমরি / সিপিইউ সময়) বিপরীতে সার্লেটের বুট-আপ / ইনিশিয়ালাইজেশন প্রচেষ্টা / সময়ের মধ্যে একটি বাণিজ্য বিকল্প।


-1

নং সার্ভলেট হয় শংকা মুক্ত না

এটি একবারে একাধিক থ্রেড অ্যাক্সেসের অনুমতি দেয়

আপনি যদি এটি থ্রেডকে নিরাপদ হিসাবে সার্লেট তৈরি করতে চান তবে আপনি যেতে পারেন

Implement SingleThreadInterface(i) কোন ফাঁকা ইন্টারফেস এটি নেই

পদ্ধতি

অথবা আমরা সিঙ্ক্রোনাইজ পদ্ধতিতে যেতে পারি

আমরা সিঙ্ক্রোনাইজড ব্যবহার করে পুরো পরিষেবা পদ্ধতিটিকে সিঙ্ক্রোনাইজ করা হিসাবে তৈরি করতে পারি

পদ্ধতির সামনে কীওয়ার্ড

উদাহরণ ::

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

অথবা আমরা সিঙ্ক্রোনাইজড ব্লকে কোডের ব্লক রাখতে পারি

উদাহরণ ::

Synchronized(Object)

{

----Instructions-----

}

আমি মনে করি যে সিঙ্ক্রোনাইজড ব্লক পুরো পদ্ধতিটি তৈরির চেয়ে ভাল

সুসংগত

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.