Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

COM+, ErrObject, and Co.

Global variables are not true global variables in VB as you might think. Every application-global, module-global, or static variable is stored in TLS, local memory of the thread where the object was created in. COM+ has a default amount of only eight threads per COM+ application and CPU initially. As the author's investigation shows, ErrObject is stored in TLS too. It means we can get that an error originated in one instance will be seen in quite different instance. Moreover, App is also kept in TLS. It means we can get that some properties of App set in one instance will be seen in another one. Moreover, Microsoft has never published the list of internal objects that are stored in TLS. Fancy, where it can lead us to! Are you frightened to death? The author shows that such architecture is not such fatal as it might seem at first sight.


advertisement
am sure you have already found out why you should be wary of static, application-global and module-global variables in COM+ components written in VB. As for me, one wonderful day I was a bit surprised at the ungrateful behavior of static variables while testing VB COM+ components under pressure. Anyway there is just a good article by Jimmy Nilsson on this topic. Have already read it? Well, let’s go further.

Some other day (but not any less wonderful) I thought what if VB ErrObject behaves as a double agent like a static or global variable? You see it is stored in TLS too. And what is about App and so on and so forth... Houston, we’ve got a problem: there are so many internal VB objects that are stored in TLS…

Confused? – Me too.



Abstract
Here are the contents of the article mentioned above, in short. Global variables are not true global variables in VB as you might think. Every application-global, module-global or static variable is stored in TLS, local memory of the thread where the object was created in (by the way it is the main feature that prevents VB objects to be pooled, I believe).

Let’s remember the features of the thread pooling in MTS and COM+.

1. There are the following features in MTS thread pooling:

1.1. There is a default restriction to 100 threads per MTS package.

1.2.  This is configurable in the following way: HKLM/Software/Microsoft/Transaction Server/Packages/{GUID of the package goes here}, value ThreadPoolMax:DWORD.

2. The COM+ thread pooling has the following restrictions:

2.1. Initially, the thread pool size is 7 plus the number of CPU on board.

2.2. The thread pool size can be increased automatically up to 10 multiplied by the number of CPU on board.

2.3. This is configurable so:  HKLM\Software\Microsoft\COM3\STAThreadPool, value EmulateMTSBehavior:DWORD. This possibility has been introduced in the Windows 2000 Service Pack 2 COM+ Rollup Hotfix 10.

You can see more detailed picture on reading MS KB Q282490 and Q303071.

Well, as you can see COM+ has a default amount of only 8 threads per COM+ application and CPU initially. It means we can get the following picture. Let’s take we create nine instances of the same COM+ component placed under COM+ and call its methods which in its turn are using global variables. The ninth instance of the COM+ component will be created in the thread that has been already used by another instance of this component. Therefore the new ninth instance will read and (oh, dear) write to the same global variables that are being used by some previous instance.

And now, contents of the current article. As my investigation shows, ErrObject is stored in TLS too. It means we can get that an error originated in one instance will be seen in quite different instance. Moreover App is also kept in TLS. It means we can get that some properties of App set in one instance will be seen in another one. Moreover Microsoft has never published the list of internal objects that are stored in TLS. Fancy, where it can lead us to! Are you frightened to death? First of all you should not believe me until I prove all I have said. Second, I will try to show that such architecture is not such fatal as it might seem at first sight.

Test, Simple but Nice
It will take five minutes to write the test revealing the behavior of VB internal objects under COM+.

1. Create a new project (COM DLL).

2. Name it Project1.

3. Add a module and paste in one string: Public g_lng As Long.

4. Inherit Class1 code from given below just by copy-paste technique:

Option Explicit Public Function Oops(ByRef er As Long, _ ByRef str As String, ByRef lng As Long) As Long



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date