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 E - PowerPoint PPT Presentation


  • 866 Views
  • Uploaded on

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

PowerPoint Slideshow about 'COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration E' - Leo


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 Applications

  • COM+ improvements

  • Neutral threading model

  • Threading model recommendations

  • Server components and threading


Com improvements just in time activation jit l.jpg
COM+ Improvements: ApplicationsJust-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 Applications

  • 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 Applications

  • 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 Applications(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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications(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 Applications(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 Applications

Object

Apartment

Object

Non Default Contexts

Object

Object

Contexts in a Windows 2000 Apartment


Compatible contexts l.jpg
Compatible Contexts Applications

  • 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 Applications(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 Applications

  • 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 Applications(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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications(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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications(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. Both ApplicationsAlmost 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. Both ApplicationsYet 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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications

  • 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 Applications(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 Applications(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 Applications

  • 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 Applications

  • COM+ improvements

  • Threading terminology

  • Neutral threading model

  • Threading model recommendations

  • Server components