Browse DevX
Sign up for e-mail newsletters from DevX


Using the COM+ Shared Property Manager with Visual Basic 6: Caching Data in the Middle-Tier : Page 3

This article describes one of the most underused features of COM+—the Shared Property Manager (SPM). The SPM can store frequently accessed data in the middle-tier, thus creating a caching mechanism that can be used by any component running in a COM+ application. By the end of this article, youll know how and when to use the SPM, as well as knowing its pros and cons.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Life Expectancy
You may wonder how long your SPM groups will reside in memory and if or when the groups will go away. The answer depends on which release mode you use when creating the groups. COM+ provides two release modes when creating SPM groups—Process and Standard.

When using the Process release mode, your SPM groups will live in memory for the entire life of the DLLHOST process for which it was created. Therefore, as soon as an object is instantiated, the SPM groups and the data in them will live in memory until the DLLHOST process ends or goes out of scope, which under normal circumstances occurs when the shutdown time for the component application has been reached (other causes are when a component application is manually shutdown or deleted).

The Standard release mode works in a slightly different fashion. Instead of staying in memory for the life of the DLLHOST process, SPM groups live until all objects in the DLLHOST process have been destroyed (using normal reference counting). For example, every time you instantiate a component, an internal counter increases by one. The opposite occurs as you destroy objects (Set object = Nothing). This means that SPM groups created with the Standard release mode are put into memory on the first object instantiation and removed from memory once the internal counter gets back to zero. Once this happens, all data in your SPM groups will be destroyed. This process starts over when the next object is instantiated and the counter increases.

In most instances, you’ll want to keep the data in SPM groups around for the life of the component application. Why? Because it increases your caching time of the data you have stored in the SPM. This means you’ll use the Process release mode much more often than the Standard release mode.

Now that we’ve covered the ReleaseMode parameter, let’s chat about the IsolationMode.

Locking Behavior
When using components to access data in SPM groups, whether it’s reading or writing, an exclusive lock is enabled. This means that all access to data in SPM groups is serialized. However, the real question is how long is the lock enabled? The answer is determined by which isolation mode you chose when creating the SPM groups. Two isolation modes are associated with the SPM: LockMethod and LockSetGet.

When LockMethod is used, the exclusive lock is enabled for the duration of the current method call. This means that if other objects are trying to access the same SPM group, they must wait until the current method has finished executing. This is useful when updating more than one property in an SPM group because it can help to ensure data consistency among all properties of the group. For example, if you have two properties in a group that are dependant on each other, the LockMethod mode can be used to update both properties at the same time, under the same exclusive lock. This will ensure that subsequent access to those properties will return the correct values.

The LockSetGet isolation mode enables the exclusive lock for a much shorter period of time. Instead of waiting until the method call is complete, the lock is turned on for only the amount of time it takes to read or write the value of a property in an SPM group. This is very useful when concurrency is of utmost importance, especially when used under a high volume, high peak load. However, the LockSetGet isolation mode is more prone to data inconsistency. Using the example of two dependant SPM properties, if you need to update both properties and you use LockSetGet, the updates to those properties will occur under two different exclusive locks instead of one. Because of this behavior, you cannot always maintain data consistency between those two dependant properties.

Note that you can certainly create SPM groups based on the LockMethod mode and SPM groups that use the LockSetGet mode. It comes down to a matter of concurrency versus data consistency. It’s important to design and create your SPM groups with those two concepts in mind.

Both isolation modes can be used for reading and writing SPM group properties. If your design is a write once/read often design, then the LockSetGet mode will probably be your choice. If your design requires many updates and many reads to SPM group properties, the safe bet is to use LockMethod. But you must also take into consideration the expected load for your COM+ application. If your load is relatively small, performing updates to SPM properties probably won’t adversely affect your application. However, if your volume is high, those write operations to SPM properties can cause severe bottlenecks in your COM+ application, thus greatly reducing the scalability of your application overall.

With all this being said, it’s important to note the SPM is not without its limitations. These are outlined below.

As you can see, the SPM is very useful for storing simple data values in the memory of a COM+ application; however, the SPM is not without its drawbacks.

First and foremost, you must resist the temptation to cache object references in the SPM. Doing so can severely affect the performance, reliability, and scalability of your application.

Another issue is that read/write operations in the SPM are non-transactional. Because of this, if you update an SPM property from within a COM+ transaction, the change is permanent, even if you rollback the transaction.

And as mentioned above, the SPM uses an exclusive lock for both the reading and writing of SPM properties, which means that all access to the SPM is serialized. Because of this, an application under heavy load that makes numerous updates to SPM properties will suffer the consequences.

OK, on to an example you can actually use.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date