Don’t use global variables in MTS/COM+ projects

Don’t use global variables in MTS/COM+ projects

Public variables at module level are thread specific. Each new thread starts get a new fresh & uninitialized copy of such variables. All the activities that are born from the same object context always run in the same apartment (You can confirm this by checking the thread ID) as if the object context had some kind of thread affinity. What i mean is this: suppose you have an MTS/COM+ object that has a method that returns the thread ID and then calls SetComplete. Each call to the method starts a new activity but the thread ID returned is always the same. This could sound tempting to store some state across activity boundaries but since the number of thread available for a package is limited (100 by default) you would end up having, under heavy stress, different activities sharing the same apartment and then the same public .bas variables. with unpredictable results.

This tip is taken from the FAQ list that Enrico mantains at his own home page (

Share the Post:
data observability

Data Observability Explained

Data is the lifeblood of any successful business, as it is the driving force behind critical decision-making, insight generation, and strategic development. However, due to its intricate nature, ensuring the

Heading photo, Metadata.

What is Metadata?

What is metadata? Well, It’s an odd concept to wrap your head around. Metadata is essentially the secondary layer of data that tracks details about the “regular” data. The regular