هل من المقبول تخزين كائنات كبيرة (مكون Java على سبيل المثال) في متغير التطبيق؟

Question

أقوم بتطوير تطبيق الآن يقوم بإنشاء وتواصل مع خادم XMPP محلي في نطاق التطبيق. يتم تخزين طرق الاتصال في CFC تتأكد من أن Application.xmppConnection متصل ومصرح به في كل مرة يتم استخدامه ، ويستخدم الاتصال لإرسال الأحداث المباشرة للمستخدمين. بقدر ما أستطيع أن أقول ، هذا يعمل بشكل جيد. ولكن لم يتم اختباره تحت أي نوع من التوتر.

سؤالي هو: هل سيؤدي هذا الإعداد إلى مشاكل في وقت لاحق؟ أنا أسأل فقط لأنني لا أستطيع العثور على أدلة على الأشخاص الآخرين الذين يستخدمون متغيرات التطبيق بهذه الطريقة. إذا لم أكن أستخدم Railo ، فسأستخدم بوابة أحداث CF بدلاً من ذلك لإنجاز نفس المهمة.

Answer 1

الحجم نفسه ليس مشكلة. إذا كنت تريد تهيئة كائن واحد لكل طلب ، فستحرق المزيد من الذاكرة. المشكلة هي الوصول.

إذا كان لديك عدد كبير من الطلبات التي تتنافس على نفس الكائن ، فأنت بحاجة إلى قياس وقت الوصول لهذا الكائن مقابل المثيل. ضع في اعتبارك أنه بالنسبة لكائنات البيانات ، يمكن لأكثر من مؤشر ترابط قراءتها. مع ذلك ، ما أفهمه هو أنه عندما يتم استدعاء وظيفة الكائن ، فإنها تغلق هذا الكائن إلى مؤشرات الترابط الأخرى حتى تعود الوظيفة.

أيضًا ، إذا حافظ الكائن على الحالة ، فأنت بحاجة إلى التفكير في ما يجب القيام به عندما تحصل على مؤشرات ترابط متعددة/إعداد تلك البيانات. هل سينتهي بك الأمر مع ظروف السباق؟

قد تفكر في التعامل مع هذا الكائن في نطاق الجلسة ، بحيث يتم إنشاء مثيل له فقط لكل مستخدم (والذي ، على الأرجح ، لن يقدم سوى طلب واحد أو اثنين من الطلبات المتزامنة).

Answer 2

بالطبع يمكنك استخدام نطاق التطبيق لتخزين هذه المكونات إذا تم استخدامها من قبل جميع المستخدمين في أجزاء مختلفة من التطبيق. الآن ، القضايا المحتملة هي:

1. حجم المكون (s)
2. الوقت اللازم للتهيئة إذا تم تعيين هذه أثناء بدء التطبيق
3. ظروف السباق بين حالات الإعداد/الحصول على حالات هذه المكونات

لأول مرة ، هناك طرق لحساب حجم مكون في الذاكرة. في الآونة الأخيرة ، كان هناك الكثير من المنشورات حول هذا الموضوع ، لذلك سيكون من السهل العثور على بعض. إذا لم يكن لديك بعض البنية الكبيرة أو الاستعلام المحفوظة في الداخل ، أعتقد أنك بخير هنا.

ثانياً ، مرة أخرى ، إذا كنت لا تملأ هذا المركب ببعض الاستعلام الكبير من DB أو القيام ببعض التحليل البطيء ، فأنت على ما يرام هنا أيضًا.

ثالثًا ، انتبه إلى المواقف المحتملة ، حيث يقوم عدد أكبر من المستخدمين بتغيير حالات هذه المكونات. إذا كان الأمر كذلك ، فاستخدم Cflock في كل إعداد للمكونات في الحالة.