Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Implementing Object Pooling with .NET Remoting - Part I : Page 2

Object Pooling is a powerful feature available when hosting .NET or COM components in a COM+ application. You may be quite surprised when you find out there is no built-in support for object pooling in the .NET Remoting infrastructure. Luckily the Remoting infrastructure is completely extensible, so you can hook into it to provide additional functionalities such as Authorization, data compression or encryption and, as you might have guessed, object pooling. That


advertisement

The Pool Manager
The Pool Manager has been defined as a SAO singleton. This class exposes a CreateObject method which accepts an assembly name and a class name and returns an object instance peeked up from the pool.
To implement Singleton behavior correctly I’ve overridden the InitializeLifetimeService method to avoid having the singleton shut down by the lease manager after a period of inactivity.
In a default configuration, the time to leave of the object is 5 minutes; lifetime is extended by 2 minutes on each call. After that period the object will be no more accessible via remoting (but not necessarily destroyed since someone could reference it locally).

'this singleton never dies Public Overrides Function InitializeLifetimeService() As Object Return Nothing End Function



Keeping track of what objects are to be marked unavailable (since passed out to a client) is quite easy since we’ve explicitly control on this. But how does the object broker may ever know when an object can be returned to the pool?
Remoting Tracking Service comes to help.
If a class implements the ITrackingHandler interface, it can be registered to the remoting infrastructure in order to receive notification when any object in the Application domain is:

  • Marshaled: this event triggers on the server side when an object is passed out to a client

  • Unmarshaled: this event triggers on the client side when an object instance is acquired (note: it fires for CAO only)

  • Disconnected: this event triggers when an object is no more accessible through remoting. The disconnect event may fire due to lease timeout or due to explicit object removal (RemotingServices.Disconnect method)

Being able to determine when an object is passed out or disconnected from the remoting infrastructure, made the implementation of the Pool Manager very simple. All I had to do was to write some plumbing code to define and manage a proper in memory structure which keeps track of the state (available/unavailable) of each object in the different pools (there is, evidently, a pool for each object type).
The simple solution I end up is the following: The Pools Manager has an instance level hash table object. Each hashtable entry contains an instance of an ObjectPool class which holds information about a specific pool. The key of each hash table entry is defined via the string concatenation of the assembly and class name of the pooled class type.
The ObjectPool class extends the HashTable class in order to store references to objects in the pool and, additionally, pool’s general information such as its max and min size.
Each entry in this hash based class holds an object which simply wraps a specific object instance in the pool (ObjInstance class). This little wrapper is simply required to flag each object in the pool with an available/unavailable flag.
Got you confused ? I think so :) . If you take a look at the picture below, you will certainly understand better the data structure used to hold object pools information.

When an activation requests arrives, the Object Broker first checks if a pool for the required object already exists. In case there is no such pool, the broker tries to get the required object type to see if it has a Pooling attribute attached. In case of a positive outcome, it creates the structure for a new object pool: creates a new Pool class, add it to the instance level hash table and then populate the pool with as many objects as specified in the Min property of the custom attribute.
 

Private Sub CreatePool(ByVal p_AssemblyName As String, ByVal p_ObjectName As String) Try 'Extract pool attributes



Enrico Sabbadin is a software developer (MCP) that works, since 1995, on distributed and Internet based applications design on the Microsoft platform. He is an author for several Italian programming magazines and for the ASPToday web site, and occasionally speaks at Microsoft MSDN conferences in Italy. Enrico maintains at his own site a MTS FAQ (http://www.sabbasoft.com).
Comment and Contribute

 

 

 

 

 


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

 

 

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