هل من الآمن استخدام كائن TAdsSettings في الموضوع الرئيسي وكائنات AdsQuery في سلاسل الرسائل الأخرى؟

Question

لدي تطبيق Win-CGI وأقوم حاليًا بتحويله إلى ISAPI.

يستخدم التطبيق أحفاد TDataset لخادم قاعدة بيانات Extended Systems Advantage.

نظرًا لأنه يمكن أن يكون هناك مثيل واحد فقط من كائن TadsSettings ، يجب أن يكون هذا في الخيط الرئيسي.

هناك حاجة إلى كائنات TAdsQuery في سلاسل الطلب.

هل سيعمل هذا العمل - أي هل ستستلزم المساحات في مؤشرات ترابط الطلبات الإعدادات العالمية من كائن AdSsettings في الخيط الرئيسي ، وهل سيكون هذا مؤشر ترابط آمن؟

Answer 1

نعم، سوف تنجح.يقوم مكون TAdsSettings بتعديل الإعدادات في Advantage Client Engine (ACE)، ومع ISAPI سيكون هناك مثيل واحد لـ ACE تم تحميله والذي تستخدمه جميع سلاسل العمليات.

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

يمكنك الحصول على مؤشر الاتصال عن طريق الرجوع إلى خاصية TAdsConnection.Handle أو استدعاء الأسلوب TAdsQuery.GetAceConnectionHandle.

Answer 2

تأكد من أن AdsQueries تستخدم المزامنة للوصول إلى إعدادات TAdsSettings مباشرةً (أو استخدم نظام مراسلة للتواصل بين سلاسل العمليات العاملة والسلاسل الرئيسية بدلاً من الوصول مباشرة) إذا لم تكن في سلسلة المحادثات الرئيسية (على سبيل المثال. System.MainThreadID <> Windows.GetCurrentThreadID)

Answer 3

لقد طرحت هذا السؤال أيضًا في مجموعة الأخبار:devzone.advantagedatabase.com، Advantage.Delphi

من أجل الاكتمال، سأضيف سؤال/إجابة أخرى من بقية هذا الموضوع:

سؤال (أنا):

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

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

الجواب (جيريمي):

سوف تحتاج إلى معالجة هذا.سيبحثون فقط في قائمة عالمية من الاتصالات للعثور على واحد بنفس المسار ، وسوف يستخدمون هذا الاتصال.ليس جيدًا في تطبيق متعدد الخيوط.

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