COM Threading and Application Architecture in COM+ Applications
Download
1 / 37

COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration Engineering (SIE) Microsoft Corporation - PowerPoint PPT Presentation


  • 825 Views
  • Uploaded on
  • Presentation posted in: Home / Garden

COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration Engineering (SIE) Microsoft Corporation. What We’ll Discuss. COM+ improvements Neutral threading model Threading model recommendations Server components and threading.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration Engineering (SIE) Microsoft Corporation

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Slide1 l.jpg

COM Threading and Application Architecture in COM+ ApplicationsMichael McKeownSupport Engineer Solution Integration Engineering (SIE)Microsoft Corporation


What we ll discuss l.jpg

What We’ll Discuss

  • COM+ improvements

  • Neutral threading model

  • Threading model recommendations

  • Server components and threading


Com improvements just in time activation jit l.jpg

COM+ Improvements:Just-in-time Activation (JIT)

  • Code

    • IObjectContext::SetAbort/SetComplete

    • IContextState::SetDeactivateOnReturn(TRUE)

  • Component Services explorer

    • Component level Enable just in time activation

      • Forces Synchronization = Required

      • Enabled if transactions checked

    • Method level auto-done property

      • Deactivate this object when this method returns


Slide4 l.jpg

Object Pooling

  • Generic instances shared at class level

    • Cannot cache user-specific state

  • Reuse expensive resources

    • Save time during activation

  • Setting in COM+ Services

    • Cannot have thread affinity

    • IObjectControl::CanBePooled

  • JIT vs. object pooling


Synchronization l.jpg

Synchronization

  • Logical boundary around mutually synchronized components

    • Example: Required and Supports

  • Set to Required if JIT or transactions

  • Only one thread at a time runs within this synchronization boundary

    • Synchronization determines when this can occur

      • Previously, apartments dictated this under Microsoft® Windows NT®


Synchronization 2 l.jpg

Synchronization (2)

  • In COM+, maps to synchronization setting

    • If none selected (and no JIT or TXs), component manages all its synchronization and can be called anytime

    • A COM+ synchronization can span many apartments and contexts

      • A context/apartment can exist in only one synchronization

    • Can span processes ONLY if you enforce it in your component architecture via call tree graph


Understand call tree frequencies l.jpg

Understand Call Tree Frequencies

  • Pay careful attention to

    • How a component will be used in call tree graph

      • Avoid blocking and odd behavior

      • Call only those components it instantiates directly or those instantiated below them in the tree

        • Avoid passing component references up or across the call tree

        • Avoid multiple callers into the same component

      • Simplifies everything and is inherently scalable

    • From what type of apartment the component will be called

      • Don’t just blindly mark as Both or Free


Understand call frequencies l.jpg

Understand Call Frequencies

  • Example: A creates B, which creates two Apartment components C and D

    • If A and B have many calls between themselves, but B has few calls between C and D

      • B should be Both to create in A’s apartment

    • If A and B have few calls between themselves, but B has many calls between C and D

      • B should match threading model of C and D

      • If B is Both and A lives in STA, B will run as STA and in same apartment as C and D – GOOD.

      • However, if A lives in MTA, and B is Both, it will run as Free and live in MTA – BAD!

      • Thus, mark B as Apartment to be close to C and D


Contexts l.jpg

Contexts

  • Set of run time attributes (Tx, Sync, etc.)

    • Tells COM+ what the required interception services are

  • Term context has roots in MTS

    • Context wrapper replaced by intelligent stub

      • Policy sets (interception)

MTS

Client

Proxy

Stub

CW

JIT

instance

COM+

COM+

Policies / interception


Contexts 2 l.jpg

Contexts (2)

  • Each instance has a context

    • Shares activator’s context if all attributes compatible

      • Calls in the same context are direct

    • Configured components rarely share context

      • JIT, Synchronization, and transaction settings

      • Certain threading model values (Apartment vs. Free)

    • Incompatible contexts will be swapped (marshaled) from activator to component

      • Allows for different interception service requirements

      • Lightweight proxy (discussed later)


Contexts 3 l.jpg

Contexts (3)

  • Can be more than one context in an apartment

  • A context lives in only one apartment

  • Default context

    • Unconfigured components with compatible threading model with their activator

    • One default context per apartment

  • Non-default context

    • Configured components with compatible attributes

    • Typically more than one per process


Contexts in a windows 2000 apartment l.jpg

Default Context

Object

Apartment

Object

Non Default Contexts

Object

Object

Contexts in a Windows 2000 Apartment


Compatible contexts l.jpg

Compatible Contexts

  • Logical boundary around instances with compatible extended attributes

    • Attributes are service-specific plus threading model

      • Transactions, Synchronization, JIT

  • Example: Component A creating component B

    • Component A: Tx = Required and Sync = Required

    • Component B: Tx = Supports and Sync = Not Supported

      Note: Both components can share a transaction boundary, but not a synchronization boundary

      • Live in different contexts


Compatible contexts 2 l.jpg

Compatible Contexts (2)

  • CA and CC are in different apartments, but may be sharing a TX boundary

  • CA and CB share an apartment boundary AND may be sharing a sync boundary

  • CC and CE are in different processes, but may be sharing a Tx boundary

P-A

A-A

A-B

CA

CC

A

D

B

CB

C

Process

P-B

A-C

CE

Apartment

G

CD

E

Context

F

Boundary


Object context l.jpg

Object Context

  • Unique to each component instance

  • Basically same dual role as under MTS

    • Data structure to hold attributes such as:

      • TX ID, Synchronization ID, SIDS, etc.

    • Service component that offers COM+ services to configured components

      • CoGetObjectContext replaces legacy GetObjectContext

        • Allows access to new COM+ service interfaces

          • IObjectContext, IObjectContextInfo, IObjectContextActivity, IContextState


Object context 2 l.jpg

Object Context (2)

struct OBJECT_CONTEXT : IObjectContextInfo, IContextState, IObjectContext, ...

{

// context properties

GUID id; // ID of this context

SYNCHRONIZATION *pSync;

APARTMENT *pApt;

bool bJITAEnabled;

bool bDone;

long nCallsInProgress;

IUnknown *pPrimaryObject;

TX_STREAM *pTxStm;

bool bRootOfStream;

bool bHappy;

// interface methods deleted for clarity

};


Interception and proxies l.jpg

Interception and Proxies

  • Direct interface pointer (same apartment and context)

    • Threading model and contexts compatible

    • No interception

  • Lightweight proxy (same apartment / different context)

    • No thread switch (executes on caller’s thread)

    • Marshals interfaces only

    • Interception services

  • Traditional proxy (different apartment or process)

    • Most expensive

      • Thread switch

      • Marshals interfaces and parameters

      • Interception services


Apartments in windows 2000 l.jpg

Apartments in Windows 2000

  • No longer the innermost execution scope of an object for configured components

    • Contexts have assumed this role

  • Maps specific threads to contexts

    • Determines which threads can call an object, not when a thread can call an object

      • Synchronization attribute now determines when


Contexts apartments and synchronizations summary l.jpg

Contexts, Apartments, and Synchronizations Summary

  • Contexts

    • Determine services required for method call

    • Belong to one apartment, but can be more than one different context in an apartment

    • Belong to at most one synchronization only

  • Apartments

    • Contain one or more contexts

    • Determine which threads can call an object

    • Synchronization can span multiple apartments

    • Each apartment exists on only one synchronization


Contexts apartments and synchronizations summary 2 l.jpg

Contexts, Apartments, and Synchronizations Summary (2)

  • Synchronizations

    • Typically span apartments and contexts

    • Ensure when serialization of calls to all components in the same synchronization

    • Every context belongs to at most one synchronization

      • If no sync, context does not belong to any synchronization


Threading terminology l.jpg

Threading Terminology

  • Apartments

    • Single-threaded apartment: STA

    • Multithreaded apartment: MTA

    • Neutral apartment (no ‘threaded’): NA

  • Confusing component terminology

    • Example: OCX versus ActiveX® control

    • x theaded component

      • x – Apartment, STA, Free, MTA, Neutral

  • Proper component terminology

    • y component or component marked y

      • y – Apartment, Free, Both, Neutral registry values


Com threading l.jpg

COM Threading

  • Components don’t live on threads

  • An instance is a ‘chunk’ of memory associated with an apartment

  • Apartments determine which threads can call the component

  • Thread switch is decided by the proxy based on apartment and threading model


Neutral threading model l.jpg

Neutral Threading Model

  • Basically a Both object

  • FTM-like marshaling capabilities for configured COM+ components

  • Cross apartment (same process) used to require a thread switch

  • Method calls from any apartment (same process) type without thread switch

    • Methods execute in the (logical) Neutral apartment (NA), but on the calling apartment’s thread

    • COM gives back standard proxy to Neutral objects for context switch and marshaling


Neutral threading model 2 l.jpg

Neutral Threading Model (2)

  • One Neutral Apartment (NA) per process

    • COM creates the NA when required

  • NA is neutral and not bound to any threads

    • No threads are bound to the NA

    • Threads don’t enter the NA like MTA/STA

      • No CoInitializeEx(COINIT_NEUTRAL…)


Neutral vs both almost identical l.jpg

Neutral vs. BothAlmost Identical

  • Operate well in Both an MTA and STA environment

    • Thread safe via synchronization primitives for MTA

      • Globals, statics, and members

    • Nothing thread specific

      • TLS, Windows handles, or code logic that assumes it is always being called on same thread

    • No operations that block STA message pump

      • Explicit calls to WFSO / WFMO avoided

      • Use new CoWaitForMultipleHandles

        • If called by STA, will enter loop during wait and pump messages

        • If called by MTA, will map to WFMO


Neutral vs both yet different l.jpg

Neutral vs. BothYet Different

  • Differ in ability to store interface pointers within the class instance data

    • Both with FTM cannot store interface pointers

      • Direct pointer passed across process without COM

    • Neutral components can store interface pointers

      • A standard proxy is returned – never direct pointer

        • COM ensures stored interface pointers in passed object’s instance data called on correct thread


Threading recommendations l.jpg

Threading Recommendations

  • Minimize mixed threading models

  • Instantiate component as close to activator as possible

    • Same apartment and same context if possible

    • Understand ramifications of extended attributes

    • Minimize thread switching if possible

  • Don’t sacrifice COM+ functionality just to shave a few milliseconds!


Apartment components l.jpg

Apartment Components

  • Recommended for MTS, but avoid in COM+ (unless called from ASP)

    • Unnecessary hidden window and marshaled calls through message loop

    • Will force Sync = Required

      • Serialization through synchronization for configured components

  • Best for page scope in ASP

    • Don’t store it in Session or Application scope


Free components l.jpg

Free Components

  • For components making blocking calls

    • Implicitly during outgoing calls outside apartment or process

    • Explicitly using WFMO, WFSO, etc.

  • Not recommended for MTS

    • Wasted synchronization code and cross-apartment marshaling

  • Great for DCOM and straight COM+

    • Okay for COM+ pooled objects (Neutral is better)

  • Not good if called from ASP (configured or not)

  • Better than Apartment if using JIT

    • Methods still serialized on synchronization lock, but not in MTA


Both components l.jpg

Both Components

  • Tastes good and is less filling

    • Runs well in both STA and MTA

  • Better than Free because good for ASP

    • Run as Apartment under ASP

  • Just as good as Free for DCOM & COM+

  • Unconfigured Both activated in creator’s context

  • Key point: MTA side must not ruin STA and vice versa


Neutral components l.jpg

Neutral Components

  • Like Both, but no thread switch

  • Can store interface pointers in instance data

  • Good in situations where different types of apartments are calling a single component

    • Avoid many-to-one in server environment

    • Good in common local applications doing logging

  • Best for COM+ pooled objects


Server components l.jpg

Server Components

  • MTS (STA activator threads)

    • Use Apartment or Both and avoid Free

      • Marshaling into MTA and unnecessary sync primitives

  • ASP (Runs as STA)

    • Use Apartment at page scope

    • Free has usual STA issues, plus

      • Security issues of proxy


Server components 2 l.jpg

Server Components (2)

  • DCOM (No ASP or COM+)

    • Incoming DCOM requests

      • If it’s an Apartment component, it will block the request until its specific thread is available

      • If it’s a Free component, call can be transferred to first available thread and no waiting

    • DCOM objects should be Free

      • Neutral does not matter in remote case

      • Neutral has limitation of not blocking calls


Server components 3 l.jpg

Server Components (3)

  • DCOM (with COM+)

    • Free is best because of COM+ MTA thread pool

    • Neutral is okay

      • No thread switch is insignificant remotely

      • Code to make it behave in STA could be hindrance


Asp components l.jpg

ASP Components

  • ASP session-scoped components (Agile)

    • Windows NT: Both with FTM

    • Windows 2000: Cannot aggregate FTM because cannot allow direct call, so choose Neutral

  • ASP application-scoped components

    • Avoid if at all possible because blocking is worse than at session scope

    • IIS 5.0 will not allow Apartment to be assigned to an Application variable


Wrap up l.jpg

Wrap Up

  • COM+ improvements

  • Threading terminology

  • Neutral threading model

  • Threading model recommendations

  • Server components


ad
  • Login