Browse DevX
Sign up for e-mail newsletters from DevX

Tip of the Day
Language: VB6,VB7
Expertise: Intermediate
Aug 3, 2002



Building the Right Environment to Support AI, Machine Learning and Deep Learning

Reduce COM+ context overhead: activate in the caller's context

Even though you may want to use some COM+ services, it doesn't mean that you have to have a unique context for each and every instance. The root instance, that is, the instance that the client uses, must have a context, but the secondary instances can often co-locate within the first context.

In Component Services Explorer there is a checkbox called "Must be activated in the callers context" that you can check for secondary components. It won't force your instances to be co-located, but you will get an error message, when they can't be.

By the way, in .NET, you can decorate the class with an attribute to get the checkbox selected. In Visual Basic. NET it looks like this:

<MustRunInClientContext(True)> Public Class MyServicedComponent
    Inherits ServicedComponent
For a component to have its instances co-located, the following must be true:
  • The COM+ application may not use component level security
  • The component may not use JIT activation
  • The component may not use COM+ transactions.
  • The component may not use events and statistics.
  • The component may not use synchronization.
  • The word 'use' above is a bit misleading. What I mean is that those services should be disabled. Since the instances will be co-located in another context and that context might use COM+ transactions, then the secondary instances will participate in the same transactions. In COM+ 1.5, Component Services Explorer helps you to avoid using incompatible settings. If you enable "Must be activated in the callers context", the necessary changes will be made.

    Jimmy Nilsson
    Comment and Contribute






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



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