Using the COM+ Shared Property ManagerBy Ramesh Balaji
|Learn More About the COM+ Shared Property Manager|
|Interested in learning more about the COM+ Shared Property Manager? If so, be sure to read: Understanding the Shared Property Manager|
In this article, I am going to deal about one of good features of COM+, which is Shared Property Manager (SPM). In a past project, I was asked to build a web site for Automobile Company with Microsoft Technologies. The Automobile Company dealt with various product lines, such as "SUV's", "CARS". In every product line there were various Products with different features; these various features were available in some products products and not available in others.
The site was implemented in a three-tiered model:
1. A Presentation Layer - combination of HTML and ASP
2. The Business Rules Layer - implemented in Visual Basic Activex dlls deployed in MTS.
3. The Data Layer - provided information about the Product Lines (the Products infomation is stored in a SQL Server Database).
Through an ASP page, the customer (Web site visitor) can select a Product Line and Product that he is interested in. This selection calls a Visual Basic Activex dll deployed in MTS which in turn queries the database for the given product line and product and returns the recordset to the ASP page. The ASP page then displays the features of the product to the customer.
The problem here was the frequent hits to the database server, since every request made by the customer required a database access. On our large site, this really caused a performance bottleneck. In trying to avoid frequent hits to the Database Server, one of the features that came to our aid was COM+ Shared Property Manager.
COM+ Shared Property Manager is a resource dispenser, which allows multiple COM+ objects to share state among each other. This means that the information in the form of an individual variable or a recordset can be shared by multiple objects within a server process. The information in the individual variable or recordset can be stored in what's called Shared Property. You can then treat the Shared Property as a dictionary object, which has name and value. The Name specifies the name of the Shared Property; the Value of the Shared Property can be a string or integer or even a recordset.
The components, which rely on the Shared Property, must run in a same application package. The Shared Property Manager eliminates possible name collisions in Shared Properties by providing Shared Property Groups, which provides Unique Name Spaces. The Shared Property Manager also implements locks and semophores, which protect Shared Properties from multiple accesses. Also, the Shared Property maintains transient state until the termination of server process. Furthermore, objects that use the Shared Properties, must have the same activation attribute - i.e. if one component is configured on the Client Process (a Base Client) while the other componentis configured to run the Server Process, they won't be able to share data the stored in the Shared Properties.
Now let me start explaining the Shared Property with a coding example. In my example, I am going to incorporate the Auto Dealer Web site scenario, except that my database will be MS-ACCESS and the number of fields in the tables will be less. Let's examine each layer of the three-tiered architecture, starting with Data Layer.
The Access Database has 2 Tables:
Product Line and
The Business Layer has a component -
clsComSharedProperty - which is an ActiveX dll
created in VB6. This component has a method called
takes two parameters. One parameter is name of the Product Line and the other is Product Name;
this method returns a Recordset, which contains the features of the Product based on the User
In Part 2 we'll look at some code in the Business Layer!