Instance properties impose constraints on concurrent execution of the different component instances. You can view and change instance properties using the Instances tab of the component’s property sheet.
If you import a component interface, you must configure
this property manually after importing the component. This information
is not stored in the EAServer repository.
EAServer supports only the ActiveX single-threaded apartment model. In the single-threaded apartment model, each component instance is bound to the same thread for the lifetime of the instance. A thread is serviced by the same connection. Multiple instances may be simultaneously active on different threads. Shared stateful resources and global data should not be used.
To implement the single-threaded apartment model for an ActiveX component, enable only the Bind Thread option in the component properties Instances tab. Although most ActiveX-enabled IDEs use the single-threaded apartment model, if a component uses the ActiveX free-threaded model (in which a single method invocation can run on different threads), the component defaults to using the ActiveX single-threaded apartment model. ActiveX components developed with Power++ support the single-threaded apartment model.
Because Visual C++ 4.2 ActiveX components use nonapartment single-threading (in which multiple instances cannot be simultaneously active) by default, you must change them to use the single-threaded apartment model by:
Not using global data, and
Marking the component’s Registry entry to indicate that the component supports the single-threaded apartment model.
The following settings specify the constraints that are placed on concurrent execution of different instances of the component. The choices are:
Concurrency – Multiple invocations can be processed concurrently; that is, multiple instances can be simultaneously active on different threads. The component must be thread-safe. Use this setting if the component code uses no volatile global data and does not share stateful resources (such as a file) among instances. This threading model offers the highest performance.
Bind Thread – Instances are bound to the creating thread. The component uses thread-local storage.
Pooling – Instances are pooled after a commit or rollback. Instance pooling allows EAServer to recycle component instances, avoiding the overhead incurred when a new instance is created each time a component is activated.
When deciding whether to support instance pooling, consider the following factors:
Instance pooling increases the efficiency of your component the most when more resources are used to initialize an instance than to clean it up. Complex structures that incur a large overhead to create are prime candidates for instance pooling. If the component does not perform a lot of initialization, it may not be more efficient for a component to use instance pooling.
Transactional components can benefit from instance pooling. Each time an EAServer transaction is committed or rolled back, EAServer deactivates the component instances that are involved. If your component does not support instance pooling, a new instance is required for each EAServer transaction that the component participates in.
You might also want to implement the IObjectControl interface in place of or in conjunction with the pooling option. Implement the IObjectControl interface if you:
Want to determine, at runtime, whether a specific instance should be pooled (do not select the pooling option—otherwise, the CanBePooled method in the IObjectControl interface will not be called), or
Need to reset the component’s state after deactivation.
Only if you are coding the component in C++ can you directly implement IObjectControl.
Sharing – A single shared instance services all client requests. Only one instance of the component can exist at any time. Attempts to create new instances when one already exists will fail.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
