Threading Models
Topic Last Modified: 2008-08-05
This topic provides information about how the different technologies compare with regard to Threading Models.
Technology | What threading models are supported? |
---|---|
Active Directory Services Interfaces (ADSI) |
This information is not yet available here. |
Collaboration Data Objects for Windows 2000 (CDOSYS) |
No specific threading prohibitions. However, applications that use free-threading should never share CDO object instances among asynchronously operating threads. |
CDOSYS SMTP/NNTP Event Sinks |
For better performance, the COM classes created as event sinks should be set to support apartment-style multithreading. |
Collaboration Data Objects for Exchange 2000 Server (CDOEX) |
No specific threading prohibitions. However, applications that use free-threading should never share CDOEX object instances among asynchronously operating threads. |
Collaboration Data Objects for Exchange Management (CDOEXM) |
No specific threading prohibitions. However, applications that use free-threading should never share CDOEX object instances among asynchronously operating threads. |
Collaboration Data Objects for Exchange Workflow (CDOWF) |
No specific threading prohibitions. However, applications that use free-threading should never share CDOWF object instances among asynchronously operating threads. Multi-threading should not be used within Workflow events. |
Exchange OLE DB Provider (ExOLEDB) |
Applications that use ExOLEDB do not directly access it, and so threading restrictions are determined by the application and ADO (or WebDAV). |
Exchange Store Event Sinks |
Event processes should not spawn any additional threads. |
Exchange Web Forms |
Exchange Web forms are scripts, and do not have threading capabilities. |
Exchange Web Services |
Application threading depends entirely on the client, and does not affect Exchange Web Services. Exchange Web Services uses HTTP, so no connection state information is retained between transactions. |
HTTP/Web Distributed Authoring and Versioning (WebDAV) |
Application threading is entirely dependent on the client, and does not affect WebDAV. WebDAV is an extension of HTTP, so no connection state information is retained between transactions. However, item status is retained in the Exchange server, for example in response to a WebDAV resource lock command. |
WebDAV Notifications |
Application threading is entirely dependent on the client, and does not affect WebDAV. WebDAV is an extension of HTTP, so no connection state information is retained between transactions. However, item status is retained in the Exchange server, for example in response to a WebDAV resource lock command. |
Incremental Change Synchronization (ICS) |
Because the ICS system provides information about incremental changes that have been made to the Exchange store, only one thread at a time should be allowed to retrieve or send data to Exchange by using the ICS interfaces. |
Lightweight Directory Access Protocol (LDAP) |
Not applicable. |
Messaging Application Programming Interface (MAPI) |
No specific threading prohibitions. However, applications that use free-threading should avoid sharing MAPI object instances among threads due to the high costs of marshalling the object. MAPI and MAPI service providers use free-threading. |
Outlook Object Model (OOM) |
Information about this is not available at this time. |
Outlook Web Access |
Not applicable. |
Exchange Rules |
Rules are defined by applications that can be multi-threaded. The resulting rules run within Exchange (server-side rules) or within Outlook (client-side rules). |
SMTP Event Sinks |
Multi-threading can be used in event sinks. |
Windows Management Instrumentation (WMI) providers for Exchange |
No specific threading prohibitions. However, applications that use free-threading should never share WMI object instances among asynchronously operating threads. WMI is most frequently used in scripted applications, where threading is not an issue. |
Exchange Backup and Restore API |
To speed the backup and restore operation, it is possible to open multiple storage groups by using multiple threads. Only one database in a storage group can be backed up at a time. Multiple threads are therefore only useful when you are backing up multiple storage groups. |
Exchange writer for the Windows Volume Shadow Copy Service |
Single threading only. When an application uses VSS and the Exchange writer to back up or restore data, the code that accesses VSS and the Writer should be single-threaded. Applications should not use multiple threads to access the VSS COM objects. |