Item 

Description 

CoClassName  

Specify the name for the object that you want to implement. The wizard generates an interface that has this name with an ‘I’ prepended and an implementation class that has this name with a ‘T’ prepended.  

Threading Model  

Choose the threading model to indicate how MTS or COM+ serializes calls to the transactional object’s interface. The threading model you choose determines how the object is registered. You must make sure that your object implementation adheres to the model selected. Threading model values are shown below.  

Transaction model  

Specify the transaction attribute that is assigned to your object when you register it. The possible values are shown below.  

Generate event support code  

Do not describe standard buttons, such as OK and Cancel.  

Model 

Description 

Single  

Your code has no thread support. Only one client thread can be serviced at a time.  

Apartment  

Under COM+, each object instantiated by a client is accessed by one thread at a time. You must protect against multiple threads accessing global memory, but objects can safely access their own instance data (object properties and members). Under MTS, it is also the case that all client calls use the thread under which the object was created.  

Both  

The same as Apartment except that callbacks to clients are serialized as well.  

Neutral  

Multiple clients can call the object on different threads at the same time, but COM ensures that no two calls conflict. You must guard against thread conflicts involving global data and any instance data that is accessed by more than one method. This model should not be used with objects that have a user interface. This model is only available under COM+. Under COM, it is mapped to the Apartment model.  

Value 

Meaning 

Requires a transaction  

The object must execute within the scope of a transaction. When a new object is created, its object context inherits the transaction from the context of the client. If the client does not have a transaction context, a new transaction context is automatically generated.  

Requires a new transaction  

The object must execute within its own transaction. When a new object is created, a new transaction context is automatically created as well, regardless of whether its client has a transaction. The object never runs inside the scope of its client's transaction. Instead, the system always creates independent transactions for the new objects.  

Supports Transactions  

The object can execute within the scope of its client's transactions. When a new object is created, its object context inherits the transaction from the context of the client if there is one. Otherwise, the object is not created in the scope of a transaction.  

Does not support transactions  

Under MTS, this setting behaves like Transactions Ignored under COM+ (see above). Under COM+, the object can’t run in the context of a transaction at all. If the client has a transaction, attempts to create the object will fail.  

Ignores Transactions  

The object does not run within the scope of transactions. When a new object is created, its object context is created without a transaction, regardless of whether the client has a transaction. This model is not supported under MTS.