السلام عليكم ورحمة الله
انا طورة نظام باستخدام ADF وبعد عمل دبلوي والتطبيق الفعلي واجهتني مشكلة انهاء ال SESSION على الرغم من اني استخدام
الاجراء الخاص بانهاء الجلسة وهو من اوراكل
public String logoutButton_action() throws IOException{
ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext();
HttpServletResponse response = (HttpServletResponse)ectx.getResponse();
HttpSession session = (HttpSession)ectx.getSession(false);
session.invalidate();
response.sendRedirect("SRWelcome.jspx");
return null;
}

وبعد الضغط على زر تسجيل الخروج لانهاء ال SESSION ,`g وذلك بعد عمل شك من خلال v$session لاتزال موجودة مع العلم انني ايضا ضبطة كل البراميتات الخاصة بالاتصال والموجودة في خصائص الابليكاشن مودل والتي ارفقتها هنا
ولكم الشكر

لا يوجد شىء مرفق عموما استخدم الميثود فى المشاركه دى لانهاء السيشن

شكرا للمجهود نفذة نفس الكود لكن ماذالت السشن موجودة بعض الضغط على زر الخروج

شكرا للمجهود نفذة نفس الكود لكن ماذالت السشن موجودة بعض الضغط على زر الخروج

ما هو الدليل على ان السيشن ما زالت موجوده عندك (سيشن السيرفر) وماذا تقصد بالخصائص الموجوده فى الابليكيشن موديول هل تقصد من البداية جلسة الاتصال بقاعدة البيانات ؟؟؟

الدليل امن اعمل استعلام للفيو v$session على الداتابيز سيرفر بلاقييها ما ذالت موجودة

الدليل امن اعمل استعلام على الفيو
v$session
بحصل الاتصال ماذال موجود مع قاعدة البيانات نعم بقصد جلسة الاتصال بقاعدة البيانات
بالنسبة لخصائص الابليكاشن بقصد الخصائص الخاصة بالاتصال للابليكاشن واللي هي ممكن اتحصل عليها عن الضغط بالزر الايمن على الابليكاشن ثم اختيار كونفيقراشن بتظهر لي خصائص الاتصال بقاعدة البيانات من بينها الخاصية
job.doconnectionpool=true

لماذا لم تقل من البداية انها جلسة الاتصال بقاعدة البيانات لان الكود المستخدم ينهى سيشن السيرفر عموما ضع ال logout كما هو بالميثود لانها ضرورية لانهاء سيشن السيرفر

اما بالنسبة للاتصال بقاعدة البيانات فالDefault فى ال application module ل jbo.doconnectionpooling هى false وليس true وكمان خللى jbo.txn.disconnect_level =1 لانهاء الجلسة عموما اقرا الموضوع ده من هنا بالتفصيل عشان تفهم الفرق بين true و false فى ال connection pool وايه الانسب بالنسبة لك

اخت هالة انا فاهم شنو jbo.doconnectionpooling و bo.txn.disconnect_level =1 انا سوت الاعادادت
jbo.doconnectionpooling TRUE وهي تعني قطع الاتصال بقاعدة البيانات بعد الفترة المحددة في الباراميتر jbo.pooltimetollife او حدة الزمن اوبنفذ صاح (بقطع الاتصال بالقاعدة) لكن المشكلة ان عدد المستخدمين عندي كتيرين مابنفذ بطريقة صحيحة الما البراميتر
bo.txn.disconnect_level =1 فهو يعني الاحتفاظ بالبزنس لوجك (كل الفيوز في الزاكرة لذيادة البيرفورمانسي في اتصال المستخدم مرة اخرى ) قمت بعمل كل الاعدادات اعلاه ولكن مازالت المشكلة قائمة

شوف

اولا: بعد ما السيشن بيحصلها destroy ال Application Module Instance بيرجع الى ال application module pool وبما انك عامل اختيار jbo.doconnectionpooling=true فبالتالى ال Application module pool حيحرر الJDBC Connection اللى كان مستخدمه وحيرجعه تانى الى ال Database pool وطبعا فى اى مره تانيه حتستدعى ال Application module Instance من ال pool مش شرط انه ياخد نفس ال Connection ولكن حياخد JDBC Connection جديد عشان يقدر يعمل reinitialize لل Business Components تانى وده بياثر على ال performance بشكل كبير

وعشان تتجنب الحكاية دى وانت عامل Do connection pool true حتخللى ال jbo.txn.disconnect_level ب 1 وبالتالى ال Business Components اللى عندك حيظلوا فى الذاكره صالحين للاستخدام حتى بعد ما ال Connection بتاعهم يحصله drop


بالنسبة للمشكلة اللى انت شايفها عندك (وانا مفترضه ان عندك ابليكيشن موديول واحد فقط او عدد من الابليكيشن موديول على ان يكونوا nested Application module ويوجد Root App module واحد فقط لهم جميعا ) فلازم تعرف ان ال Application Module Pool هى اللى بتهندل ال Database Connection ومفيش طريقه نعرف بيها امتى ال Database Connection ده بيحصله release (أعتقد ان الطريقه الوحيده اللى ممكن نعرف بيها هى بعد مرور فترة ال time out اللى بنحددها على السيرفر ) فما دام عدد ال connections لم يزيد الى حد كبير فلا توجد مشكلة تستدعى ضرورة اغلاق الConnection فى الحال

إن قطع الاتصال بقاعدة البيانات لا يعتمد على user session ويجب التفرقة بين user session و database session.
أنت قمت بإغلاق user session ثم وجدت أن database session لا يزال موجوداً وهذا بالفعل ما يحدث لأنه يعتمد بالدرجة الأولى على إعدادات الـ time out ,gذلك لن يتم قطع database session مباشرة.
أيضاً يجب ملاحظة انه إذا استخدمت data source ولم تتجاوز الحد الأقصى فلن يتم إغلاق الاتصال مطلقاً

اخت هالة انا شغال في بيئة عمل كبيرة حدا ممكن تتخيلي ان عدد فروعنا 50 فرع او عدد المستخدمي قد يصل الى 300 مستخدم لحظة واحدة بالفعل عندي مشكلة في عدد السيشن انا عملت كل الاعدادات السابقة والازمة او عملت الباميتر pooltimetolive 5 دقائق او فعلا بنفذ بقطع الاتصال اذا ذاد عن 5 دقائق لكن بعد ما يتم استخدام البرنامج لعدد كبير 20 مستخدم على سبيل المثال لا يعمل البراميتر ولا يستطيع التعامل مع النظام لان العدد الاقصى للمستخدمين المحدد في الابليكاشن 70 متزامنين

اخ sd4it مشكور على الافادة ذي ما وضحت ان هل من الممكن قطع database session من داخل application module

قطع database session من داخل application module يعتمد على إعدادات الـ time out ولكن لكي تصل إلى عدد أكبر من المستخدمين المتزامنين فيجب عليك عمل clustering حيث أنه لدينا مشروع يصل عدد المستخدمين المتزامنين إلى أكثر من 2000 وهذا لا يمكن تحقيقه إلا باستخدام clustering

اولا: لا توجد طريقه لقطع الاتصال مباشرة بعد انهاء السيشن عن طريق ال Application module وبعدين خللى بالك الباراميتر اللى اسمه timetolive معناه انه حيحرر ال connection بعد خمس دقايق اذا لم يستخدمه احد ولكن اذا يوزر تانى استخدمه فلن يحدث له release

واعتقد ان مشكلتك بقيت مشكلة حلها من عند الابليكيشن سيرفر اللى بتستخدمه فى عمل الديبلوى فمثلا هل حاولت زيادة ال Maximum Capacity فى ال Connection pool على السيرفر ؟؟؟؟

هل حاولت تحديد فترة Inactive Connection Timeout على السيرفر بحيث ان ال Inactive Connection يرجعوا تانى لل Pool بعد مرور فترة معينه؟

اخت هالة مشكورة على التواصل هل الخصائصية nactive Connection Timeout خاصة بالداتابيز سيرفر ؟

اخ sd4it ممكن توضح كيف استخدم clustering ؟ وهل تعني clustering database ?

خاصية ال Inactive Connection Timeout يتم تحديدها بالثوانى على السيرفر سواء بتستخدم الابليكيشن سيرفر او الويب لوجيك وهى تمثل الفتره اللى بعدها يعيد السيرفر ال Connection الى ال pool

واعتقد ان الاخ / sd4it يقصد عمل cluster على السيرفر نفسه لتجنب حدوث ال failover بعمل عدد من ال server Instances

أنا أقصد عمل cluster في الوب لوجيك ولكن هذا لا يمنع عمل cluster على قاعدة البيانات بحيث تقوم بتنفيذ Oracle RAC لأن هذا ما يضمن أن تكون الأنظمة High Available