صف بالتفصيل آلية إدارة الجلسة في Tomcat:
1. عملية الجلسة أثناء عملية الطلب:
وصف موجز: أثناء عملية الطلب ، قم أولاً بتحليل معلومات SessionId في الطلب ، ثم قم بتخزين SessionId في قائمة المعلمات للطلب. ثم عندما تحصل على الجلسة من الطلب ، إذا كان SessionId موجودًا ، فستحصل على الجلسة من تجمع الجلسة بناءً على المعرف. إذا لم يكن SessionId موجودًا أو فشل الجلسة ، فقم بإنشاء جلسة جديدة ووضع معلومات الجلسة في تجمع الجلسة للاستخدام التالي.
(1) مخطط توقيت عملية التحليل SessionID:
نظرة عامة: أولاً ، يرسل المستخدم طلب HTTP لتمريره إلى http11processor ، ثم ينقله إلى coyoteadapter عبر http11processor. coyoteadapter هو محول يتكيف مع org.apache.coyote.request مغلفة بواسطة إطار Coyote إلى org.apache.catalina.connector.request (لن أقول الكثير عن هذه العملية ، التي تم تلخيصها من قبل). بعد التحويل ، سيتم استدعاء طريقة parsepathparameters لتحليل معلومات ملفات تعريف الارتباط في معلمات المسار (لأنه عندما يتم تعطيل ملف تعريف الارتباط بواسطة المتصفح ، سيتم إعادة كتابة معلومات ملف تعريف الارتباط في عنوان URL). أولاً ، حاول تحليل SessionId من عنوان URL. ثم سيتم استدعاء parsesessionCookoOkiesId. هذا هو تحليل SessionId من ملف تعريف الارتباط وتخزينه في الطلب (parsepatharameters وأساليب parsesessionoCoOkoOkiesId. أثناء عملية المكالمات ، لا يوجد منطق XOR واضح ، أي أنه يتم تنفيذ كلاهما ، لكن ليس هناك مشكلة في ذلك ، فلن تفكر في ذلك ، فلا توجد مشكلة في ذلك ، فهناك لا توجد مشكلة في ذلك. مشكلة). التحليل إلى SessionId ووضعه في الطلب. لا بأس في تحليل منطق SessionId.
يتم نشر رموز المفاتيح التالية:
طريقة parsepathparameters (تم تحليلها من إعادة كتابة عنوان URL):
ملاحظة: الأجزاء المحددة هي تحليل المتغيرات من عنوان URL ثم وضعها في قائمة معلمات الطلب.
طريقة parsesessionCookoOkiesId (تحليل SessionId من ملفات تعريف الارتباط):
ملاحظة: العلامة أعلاه هي الحصول على SessionId من ملف تعريف الارتباط. انظر إلى العلامة الأولى مع مكالمة إلى SessionConfig.getSessionCoOkIename (السياق) ، هنا ستحصل على مفتاح SessionId الافتراضي. يتم تعريف هذا المفتاح في SessionConfig ، وقيمته هي jsessionid:
(2) عملية الحصول على جلسة من الطلب هي أساسا كما هو موضح أعلاه. ثم ألقِ نظرة على عملية الحصول على جلسة في Servlet:
نظرة عامة: AppServlet هي servlet التي نحددها أنفسنا. عندما نحصل على الجلسة من خلال reqest ، فإن httpservletrequest (واجهة) تسمى في الواقع requestFacade (واجهة تغلف org.apache.catalina.connector.request) ، ومن ثم سوف يدعو requestFacade طريقة gettess للطلب الحقيقي. المنطق المحدد للطلب هو استدعاء طريقة GetManger لحاوية السياق للحصول على مدير الجلسة (تم وصف تفاصيل مدير الجلسة أدناه). إذا تم تحليل SessionId ، فسيتم استدعاء طريقة الاكتشاف للحصول على الجلسة المقابلة من تجمع كائن الجلسة. خلاف ذلك ، إذا لم يكن SessionId موجودًا ، فيجب إعادة إنشاء الجلسة ووضعها في مجموعة كائنات الجلسة.
يتم نشر رموز المفاتيح التالية:
طريقة getsession من requestFacade:
طريقة GetSession لطلب الفصل:
طريقة DoGetSession لطلب الفصل:
ملاحظة: العلامة الأولى هي الحصول على معلومات الجلسة من تجمع كائن الجلسة استنادًا إلى SessionId ، والعلامة الثانية هي إنشاء كائن جلسة جديد دون تحليل SessionId.
هذا يخلق جلسة جديدة. تتضمن هذه النقطة توليد SessionId الجديد. يتم تعريف رمز المفتاح المنطقي لتوليد SessionId في طريقة generatesessionId في مولد SessionId Class:
ما سبق هو عملية الحصول على جلسة Servlet. تلخص التفاصيل التالية كيف يدير Tomcat جلسة ، أي معرفة مدير الجلسة.
2. آلية إدارة الجلسة
تعريف مدير الجلسة: يكون مكون مدير الجلسة مسؤولاً عن إدارة كائنات الجلسة ، مثل إنشاء وتدمير كائنات الجلسة.
أولاً ، دعونا نلقي نظرة على مخطط بنية ميراث الفصل لمدير الجلسة (هذا هو الرسم البياني لـ TOCMAT7.x ، وآلية ميراث الفصل في TOMCAT5 تختلف تمامًا عن هذا):
وصف موجز: ما يلي يلخص كل فئة بدوره (راجع معلومات الموقع الرسمي):
(1) المدير: يحدد الواجهة الأساسية المرتبطة بحاوية معينة لإدارة تجمع الجلسة.
(2) ManagerBase: يقوم بتنفيذ واجهة المدير ، والتي توفر تنفيذ وظائف مشتركة لمدير الجلسة.
(3) StandardManager: يرث من ManagerBase ، مدير الجلسة الافتراضي (لا يحدد التكوين ، استخدم هذا بشكل افتراضي). إنه تنفيذ غير cluster لجلسات معالجة Tomcat (أي النسخة المستقلة). عندما يتم إغلاق Tomcat ، سيتم استمرار معلومات جلسة الذاكرة على القرص وحفظها كجلسة ، وسيتم استعادتها عند التمهيد مرة أخرى.
(4) PerferenceManagerBase: موروثة من Managerbase ، وتنفيذ وتحديد الوظائف الأساسية لاستمرار مدير الجلسة.
(5) مثال على ذلك: ورث من perfectManagerBase. الوظيفة الرئيسية هي تبادل كائنات جلسة الخمول (عن طريق تعيين وقت المهلة) على القرص.
(6) ClusterManager: إنه ينفذ واجهة المدير ، ويجب أن تخمن اسم الفصل. هذا هو المدير الذي يدير جلسة الكتلة ومدير الجلسة للنسخة المستقلة StandardManager أعلاه هي مفاهيم نسبية. تحدد هذه الفئة واجهة التكرار والمشاركة في الجلسات بين الفصول.
(7) ClusterManagerBase: ينفذ واجهة ClusterManager ويرث من ManagerBase. ينفذ هذا الفصل العملية الأساسية لتكرار الجلسة.
(8) BackupManager: ورث من ClusterManagerBase ، وهو تنفيذ استراتيجية النسخ المتماثل للجلسة بين الكتلة. لا يوجد سوى عقدة احتياطية واحدة في بيانات الجلسة ، وجميع العقد في الكتلة مرئية في موقع العقدة الاحتياطية هذه. يمنح هذا التصميم ميزة في دعم عمليات النشر غير المتجانسة.
(9) Deltamanager: ورثت من ClusterManagerBase ، وهو تنفيذ استراتيجية تكرار جلسة الكتلة. على عكس BackupManager ، سيتم نسخ بيانات الجلسة إلى جميع العقد الأعضاء في الكتلة ، مما يتطلب أن تكون جميع العقد في الكتلة متماثلة ويجب نشر نفس التطبيق.
الملحق: دعنا نلخصها بالتفصيل أدناه. يوجد متجر متغير عضو في فئة ProsisterManagerBase:
يتم تعريف استراتيجية التخزين لمدير الجلسة المستمر بواسطة كائن المتجر هذا. هيكل الميراث الطبقي لهذا المتجر كما يلي:
وصف موجز: يوفر متجر الواجهة وأمثلةه مجموعة من استراتيجيات التخزين لمدير الجلسة. يحدد المتجر الواجهة الأساسية ، ويوفر قاعدة المتجر التنفيذ الأساسي. تتمثل السياسة التي تنفذها فئة Filestore في تخزين الجلسة في ملف محدد في الدليل مع setDirectory () وإنهاء مع .session. تقوم فئة JDBCSTORE بتخزين الجلسة في قاعدة البيانات من خلال JDBC. لذلك ، من الضروري استخدام JDBCSTORE. تحتاج إلى استدعاء طريقة setDriverName () وطريقة setConnectionUrl () على التوالي لتعيين اسم السائق وعنوان URL للاتصال.
3. التكوين المتعلق بالجلسة Tomcat
لخص التكوين والإعدادات المتعلقة بالجلسة من مستويين. بادئ ذي بدء ، من مستوى ملف التكوين ، يكون للجلسة وقت انتهاء الصلاحية ، ويتم تعريف وقت انتهاء الصلاحية الافتراضي في $ catalina_home/conf/web.xml. التكوين الافتراضي المحدد هو كما يلي (وقت انتهاء الصلاحية الافتراضي هو 30 دقيقة ، أي أنه لا يوجد وصول في 30 دقيقة ، وتنتهي الجلسة):
نقطة أخرى هي أنه في حالة عدم تكوين إدارة الجلسة ، يتم استخدام StandardManager افتراضيًا. ومع ذلك ، إذا كنت ترغب في تكوينه ، فيمكنك تحديده في $ catalina_home/conf/context.xml (من هذا التكوين ، يمكنك أن ترى أن مدير الجلسة يرتبط بحاوية السياق ، مما يعني أن كل تطبيق ويب سيكون له مدير جلسة). التكوين المحدد هو كما يلي:
Tomcat7.x الافتراضية لتكوين هذا المدير. إذا كان المدير الخاص الذي تريد تحديده هو المدير الافتراضي ، فيمكنك تحديده على هذا النحو:
في الواقع ، بعد أن رأيت ذلك ، اكتشفت أنه يمكن تخصيص سياسة تخزين الجلسة أو المتجر طالما تم تنفيذ الواجهة ذات الصلة. لا بأس في كتابة تكوين بنفسك هنا.
بالإضافة إلى ذلك ، دعنا نلخص من مستوى الكود: تتم كتابة بعض معلومات التكوين للجلسة في الكود ، على سبيل المثال ، تحدد فئة SessionConfig بعض معلومات إعداد الجلسة. اسم الجلسة في ملف تعريف الارتباط هو jsession. عندما يتم وضع الجلسة في المسار من خلال إعادة كتابة عنوان URL ، فإن اسم القيمة الرئيسية هو JSessionIDs. الرمز المحدد كما يلي:
نقطة أخرى هي أن الطول الافتراضي المحدد لـ SessionId هو 16 بايت ، وهو محدد في SessionIdGenerator:
حسنًا ، يتم تلخيص الكثير حول التكوين الافتراضي.
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.