Caching Sessions and Scripts

Your handler's design depends in part on the number of folders it will be used in and the workload (number, or volume, of events) it will carry within a folder. One affected design element is whether to cache a CDO session and a script. Consider the following cases:

• Few folders, high volume per folder For example, an agent functioning as a distribution list could broadcast any item posted to the monitored folder to the members of the list. Caching the members of the list could help in this example since list membership is not likely to change as often as messages are being posted.
• Many folders, low volume per folder Caching would be less helpful in this case.
• Many folders, high volume per folder An example of this case is a script agent used in many folders on a server; This case could occur, for example, when many of a system's recipients use script agents in folders within their private mailboxes. Caching information specific to each mailbox would probably help in this case.

In general, caching is more likely to help if high volume is involved.

In the case of the Microsoft Exchange Scripting Handler, if a new CDO session (which includes a logon to MAPI) had to be created every time a script fired, performance would suffer greatly. In this case, the session object (using the mailbox of the script author) is cached, which helps greatly. In other words, if a new script is run whose author also created another recently run script, that person's CDO session, having been cached, is reused. The script itself is also cached, to be used when the next event triggers it.

CDO Sessions and MAPI Sessions

The session that is passed to you is a MAPI session from the service, not a CDO session. This precludes Microsoft Visual Basic handlers from using it, because Visual Basic can only manipulate the IDispatch interface, an interface that MAPI does not support.

If your custom agent is written in Microsoft Visual Basic, it will need to perform its own CDO session logon.