+- Atozed Forums (https://www.atozed.com/forums)
+-- Forum: Atozed Software (https://www.atozed.com/forums/forum-1.html)
+--- Forum: IntraWeb (https://www.atozed.com/forums/forum-3.html)
+---- Forum: English (https://www.atozed.com/forums/forum-16.html)
+----- Forum: IntraWeb General Discussion (https://www.atozed.com/forums/forum-4.html)
+----- Thread: ISAPI DLL, ADO and ComInitialization (/thread-2049.html)
ISAPI DLL, ADO and ComInitialization - ebob42 - 10-12-2020
Hi All,
I have a question regarding the correct value of the ComInitialization property.
We're using data pooling, and on the datamodule a TADOConnection component and TADOQuery (we're migrating to FireDAC soon, but have ADO for now).
I always believed that for an ISAPI DLL, IW does not do any COM initlization, since IIS will take care of that, so we've left COMInitialization set to ciNormal (and could probably also have left it as ciNone). See also http://codeverge.com/embarcadero.delphi.intraweb/com-initialization-not-done-durin/1047897
However, there's now a discussion because the manual (from 2002) says we should use ciMultiThreaded, as can be read in chapter 7.5 of http://downloads.atozed.com/intraweb/IntrawebManual.pdf
What's the official word about this? When using ADO in pooled data modules, should we use COMInitialization set to ciMultiThreaded? Or should we call CoInitializeEx ourselves? Or leave COMINitialization set to ciNormal or coNone? Experience quite a performance degradation with more than a few dozen concurrent requests (the pool is big enough, but the delay is not linear)...
Thanks for any insight.
Groetjes, Bob Swart
One more question: if we change the value of COMInitizatiion, while ISAPI DLl is already running (so we change it in code), will that have effect for any new incoming requests, or should we reload the ISAPI DLL instead?
RE: ISAPI DLL, ADO and ComInitialization - kudzu - 10-12-2020
I would have to look to be sure and I'll let Alexandre confirm, but from memory:
1) It has no effect in ISAPI. Its for SA.
2) It cannot be changed once the app has started.
3) IIS already calls ComInit for ISAPI apps.
RE: ISAPI DLL, ADO and ComInitialization - ebob42 - 10-14-2020
Thank you for your answer, it would be great it Alexandre to confirm this, please.
RE: ISAPI DLL, ADO and ComInitialization - Alexandre Machado - 10-14-2020
Hi Bob,
Com Initialization is not recommended since IIS 6, IIRC, for ISAPI, so it must be set as ciNone.
COMInitialization = ciMultiThreaded was required for older versions of IIS.
This is the Microsoft link:
https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525934(v=vs.90)
RE: ISAPI DLL, ADO and ComInitialization - ebob42 - 07-04-2025
Hi Alexandre,
I have a follow-up question regarding this... I understand that IIS is using a threadpool with threads that are already COM-initialized to handle the incoming ISAPI DLL requests. So that works fine.
However, what about threads that we create ourselves within the ISAPI DLL? For example, in order to fulfill a request, we create new threads or tasks in our Delphi code, and let them use a data module from the data module pool or perform other operations that require COM initialization to be set.
We assume we need to call CoInitialize (and UnCoInitalize) in these cases.
My question is: are we correct? Should we call CoInitialize(nil)? Or perhaps CoUnInitialize(0, COINIT_MULTITHREADED) instead? Or nothing at all? (I assume threads we create manually inside the ISAPI DLL are not taken from the IIS threadpool).
Groetjes, Bob Swart
PS: When I check the IntraWeb source code unit IWServerControllerBase, I see that CoInitialize or CoUnitialize are not called when the ComInitialization property is set to ciNone (which it is in our ISAPI DLL), which covers the incoming requests handled by threads from the application pool. I see no other calls to CoInitialize...