Hey Group,
Today we will discuss about COM+ features that we mentioned yesterday.
Let us first discuss the JOTS features. These features were present in MTS and are present in COM+ Service also.
Just-In-Time Activation: - Object creation by itself is a very expensive process hence before instantiating an object we need to consider a lot of parameters like the amount of memory it will take, how many objects will be created at any given point of time, after instantiating objects how will we deallocate its memory, etc.
Just-in-time Activation allows the developer to create an object once and then use it wherever required without worrying about resources consumed by that object. This is because behind the scenes JIT deallocates the memory when the object is not used and then reallocates then when the client references the object or calls any method on them. Thus the client can hold references to as many objects required coz COM+ will provide objects whenever necessary and deallocate them when required.
Since JIT deallocates memory it is quite possible that it may dellocate memory between two function calls, thus there is no guarantee that the same property values will be available between subsequent calls. Hence the COM+ objects should ideally be stateless (i.e. should have properties).
Object Pooling: - We just discussed JIT and saw how COM+ handles its memory allocation and deallocation coz object creation is an expensive process. Further on to that COM+ even allows you to create an object pool to reuse objects that are created. Whenever any COM+ client releases an object COM+ does not destroy the object if ObjectPooling is enabled but sends the object to the Pool to reuse the object when some other client asks for the same.
By Nature object Pooling can share the object instance between several clients. Thus if you have properties in your class they will be shared across all the clients. Hence to avoid this it is a good practice to create class that are stateless. So that in between function calls there is no need to maintain the state.
Note: - JIT and Object Pooling together make the heart of COM+. Object Pooling may have a pool of objects reusable across clients but its JIT that decides its allocation and deallocation. Thus making the objects stateless is a very good practice coz then we can use both the services effectively as our classes reduce to function libraries.
Transaction Enforcement: - There are 5 transactions types that can be used with COM+. Whenever an object is registered with COM+ it has to abide either to these 5 transaction types.
Disabled: - There is no transaction. COM+ does not provide transaction support for this component.
Not Supported: - Component does not support transactions. Hence even if the calling component in the hierarchy is transaction enabled this component will not participate in the transaction.
Supported: - Components with transaction type supported will be a part of the transaction if the calling component has an active transaction.
If the calling component is not transaction enabled this component will not start a new transaction.
Required: - Components with this attribute require a transaction i.e. either the calling should have a transaction in place else this component will start a new transaction.
Required New: - Components enabled with this transaction type always require a new transaction. Components with required new transaction type instantiate a new transaction for themselves every time.
Security: - This is another important aspect of COM+. This allows granting access rights to users at component level. COM+ allows you to create roles and add users to these roles. Hence when a user tries to instantiate an object COM+ checks the users role. You can define different roles and access rights for these roles. If the user is in role defined he/she will be granted rights as defined for that role.
