As explained in Chapter 8, queued components under COM+ 1.0 require the presence of a domain controller to provide authentication for the queued call. If you do not have a domain controller, you must turn off COM+ 1.0 application authentication (set it to None). COM+ 1.5 provides better configurable support for queued calls by separating them from normal synchronous calls. The application Queuing tab now lets you configure authentication for queued calls explicitly (see Figure B-8). Your available options are to:
Use MSMQ domain controller authentication when the application is configured to use authentication for synchronous calls (when the application authentication is set to any value except None).
Never authenticate queued calls into this application. Choosing this option allows you to use queued components freely without a domain controller.
Always authenticate incoming queued calls, regardless of the application authentication setting.
The Queuing tab also allows you to control the maximum number of concurrent players the application can contain. Because every player is created on a separate thread, some overhead is associated with creating and maintaining a player. In extreme situations, your application may grind to a halt if the number of concurrent players is too large (a few hundred). When you set a limit on the number of players and that limit is reached, the listener does not create new players. Rather, queued calls remain in the application queue, allowing calls in progress to execute and complete. The limit is also good for load-balancing purposes and can be used in conjunction with application pooling, discussed next.
The COM+ 1.5 Catalog lets you configure the queuing support
programmatically as named properties of the application catalog
object. The authentication level is accessible via the
QCAuthenticateMsgs
named property, and the maximum number
of players is accessible via the
QCListenerMaxThreads
property.