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

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

et’s face it. Caching is a fancy was of saying that you are going to save some type of data somewhere. In the n-tier web application model, your tiers are typically made up of the presentation layer (ASP), the business logic and data access layer (COM+), and the backend data layer (SQL Server, DB2, Oracle, etc). Each tier has its own ways of caching data. In ASP you can use the Application object, which is useful for storing data that seldom changes, such as XML or HTML menus, while databases are the best place to maintain user state. To cache data in the middle-tier, COM+ provides the SPM.

Side note: when caching data, cache data relevant to the tier the data resides on. For example, do not cache HTML menus in the SPM. By doing that, you must make a component call from ASP to the middle-tier just to get an HTML menu, which is presentation layer data. See what I’m getting at?

The SPM is not exactly shared memory, but can be easily used to perform similar functionality. Visual Basic developers can use the COM+ Services Type Library to invoke the SPM and manage cached data within COM+ applications. This article will demonstrate how to use the SPM from Visual Basic 6, as well as provide an in-depth description of the SPM from a Visual Basic programmer’s perspective (to use the SPM, create a reference in Visual Basic to the COM+ Services Type Library; this will expose the interface needed to manage SPM groups and properties).

Data in the SPM is managed within groups, which in turn contain properties. SPM properties are similar to that of a dictionary object. Meaning, they are used as name/value pairs. This lets you assign and retrieve values of SPM properties based on their names. SPM groups are also given names, which allow you to manage any number of different groups, each containing any number of different properties.

To begin, let’s review the architecture behind COM+ applications.

COM+ Applications and the DLLHOST Process
Let’s continue the discussion by reviewing how COM+ manages components. First, there are two types of COM+ applications: server and library. Server applications are out-of-process while library applications are in-process; meaning, library applications run under the process and context of the calling application. COM+ server applications are housed in a process called DLLHOST.EXE, and each server application has its own unique DLLHOST.EXE process. This process is managed by COM+ and is assigned its own process ID (PID); this allows you to view the processes for COM+ server applications within Task Manager. (Note: The PID becomes important when troubleshooting hangs or crashes of COM+ server applications. The Status View in Component Services displays the PID for each server application. You can then use Task Manager to find the PID in question and view its CPU usage, memory usage, thread counts, handle counts, etc. At that point, you could issue a kill command on the process experiencing difficulty.)

Why is any of this relevant to the SPM? As you’ll see later on, data in the SPM resides in the memory of a COM+ server application the DLLHOST process. So it’s important to know that data in the SPM can be used only by components in the same DLLHOST process. A component running under one COM+ server application cannot access data in the SPM of another COM+ server application. Cross-process accessibility is not available for the SPM.

The diagram below shows two COM+ server applications. Each has its own set of components, as well as SPM groups and properties. The components in COM+ application A can only access the SPM for its own DLLHOST process. Conversely, components in COM+ application A cannot access data in the SPM of COM+ application B.

OK, now onto some code.

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