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.  

Description 

Enter an optional description of the data module you are creating.  

Threading Model  

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

Transaction model  

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

Model 

Description 

Single  

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

Apartment  

Under COM+, each module instantiated by a client is accessed by one thread at a time. You must protect against multiple threads accessing global memory, but modules 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 module was created.  

Both  

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

Neutral  

Multiple clients can call the module 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 module 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 module must execute within the scope of a transaction. When a new module is created, its module 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 module must execute within its own transaction. When a new module is created, a new transaction context is automatically created as well, regardless of whether its client has a transaction. The module never runs inside the scope of its client's transaction. Instead, the system always creates independent transactions for the new objects.  

Supports Transactions  

The module can execute within the scope of its client's transactions. When a new module is created, its module context inherits the transaction from the context of the client if there is one. Otherwise, the module 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 module can’t run in the context of a transaction at all. If the client has a transaction, attempts to create the module will fail.  

Ignores Transactions  

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