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 groupsProcess
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
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.
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.
that we’ve covered the ReleaseMode parameter, let’s chat about the IsolationMode.
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.
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.
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.
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.
all this being said, it’s important to note the SPM is not without its limitations.
These are outlined below.
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.
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.
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.
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.
on to an example you can actually use.