|
|
|
|
| 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. |
|
|
|
|
|
|
Submitted By :
Nayan Patel
(Member Since : 5/26/2004 12:23:06 PM)
|
 |
|
|
Job Description :
He is the moderator of this site and currently working as an independent consultant. He works with VB.net/ASP.net, SQL Server and other MS technologies. He is MCSD.net, MCDBA and MCSE. In his free time he likes to watch funny movies and doing oil painting. |
|
View all (893) submissions by this author
(Birth Date : 7/14/1981 ) |
|
|