Implementing Object Pooling with .NET Remoting – Part II

Implementing Object Pooling with .NET Remoting – Part II

he Pool Manager described in the first part of this article series had a couple of problems. The process of acquiring a pooled object was not transparent to the client, which couldn’t simply new the object (provided that the required type had been registered in the remote configuration file). The client had to contact the broker explicitly to acquire a reference to an object in the pool.

The second problem lies in the fact that objects returned by the broker are CAO types. This is far from optimal. The client must explicitly release the object when done with the object calling Dispose. If it fails to do so, the object is returned to the pool only when the object Lease time is expired.

Properly designed pooled objects don’t keep any client specific state across calls, thus for this reason it would be highly desirable to pass back to clients SAO SingleCall object types. This optimize the pool management, not letting the client hold a reference to a pooled object longer than necessary.

Activation Transparency and SingleCall Behavior via a Custom Channel Sink
Remoting behavior can be customized in two ways: defining a custom proxy or inserting a custom sink in the default sink chain. The custom proxy approach is not so compelling, since you cannot insert a custom proxy transparently (the client must explicitly create it) and anything you can do with a custom proxy can actually be done using a custom sink.

We will then opt for a custom sink to enable transparent activation and SingleCall behavior for our pooled objects. The solution we will come out with won’t work for Client Activated objects, but as I said, CAO are not a desirable option when working with pooled objects.

Anyway, note you still can get CAO behaving objects when accessing the Pool Manager explicitly.

Custom Sinks and Custom Sink Providers
Setting up a custom sink requires the development of two classes: the custom sink class itself and a custom sink provider class. The latter has to be registered into the remoting infrastructure. The sole role of the sink provider is to return to the remoting infrastructure an instance of its associated custom sink when required.

Here is a remote configuration file where a custom sink provider is registered before the formatter

 Modifying Messages   and Headers
In order to decide how to hook into the remoting infrastructure you have to know what and how a message body and a message header can be modified within a custom sink.

The message body holds information such as the target class and method and method’s parameter values. The header basically holds the URL remoting will use to identify the object on the server side.

The message format changes while traveling along the sinks. Before the formatter on the client side, or after the formatter on the serve side, the message is exposed to custom sinks as a .NET provided object implementing the IMessage interface. You can easily examine all the Message properties but, unfortunately, it comes out that only the method’s parameter values can be modified within a custom sink, other properties are read only.

The message is build by the Transparent proxy (an entity which can’t be overridden or customized) and the methods which would let us build a new message from scratch are defined as protected.

Of course we can do whatever we like with the message when it’s turned into its stream based form (after the formatter on the client side or before the formatter on the server side). Unfortunately in this case it’s much more difficult to modify it.

It is somehow feasible if the selected formatter is the SOAP one. If the selected channel formatter is the binary one this is practically impossible since the binary format is Microsoft proprietary.

With such limitations in mind, let’s concentrate on URL modification to trick client activation requests.

The idea is basically the following. If we put a custom sink on the server side after the formatter we can intercept the message and proceed as follow:

  • The required type is extracted from the message.

  • A check is made to see if the class is poolable (that is, if the Pooling attribute is attached to the class).

  • If it is, the Pool Manager is contacted via a shared method and asked to return an instance of the specified type from the pool.

  • A random URI (I use GUIDs) is defined and the acquired object instance is explicitly published via the RemotingServices.Marshal method using that URI.

  • The header URI property is modified to have the message request target the published object (the URI provided by the client could have been any dummy one since it’s overridden at this stage).

  • The request is forward to the next sink.

  • On return the object is disconnected from remoting (RemotingServices.Disconnect), thus providing SingleCall semantic.

Unfortunately this approach has a drawback. After .NET Framework SP2, the formatter itself checks if the specified object URI in the header is a valid one and raise an error if it’s not the case (this didn’t happen before SP2; this check was done later in the sink chain). For this reason I had to move the custom sink before the formatter. Unluckily doing this you need to modify slightly the technique described above.

Before the formatter the message is in its byte stream form, thus making hard to find out what object the client is trying to activate.

The easier way to pass this information is to define a standard for the URI format the client must specify to activate a pooled object. This format must contain the required class name and the assembly name where the class is defined.

The required format is:


In the custom sink the URI is read from the message header and the assembly and class name information are extracted from the URI string. From this point on, the steps are the same as described above.

In the step-by-step commented code listing below you can see the described technique in action:

Public Function ProcessMessage( _    ByVal sinkStack As IServerChannelSinkStack, _    ByVal requestMsg As IMessage, _    ByVal requestHeaders As ITransportHeaders, _    ByVal requestStream As Stream, _    ByRef responseMsg As IMessage, _    ByRef responseHeaders As ITransportHeaders, _    ByRef responseStream As Stream) As ServerProcessing _    Implements IServerChannelSink.ProcessMessage    Dim l_objmarshalbyref As MarshalByRefObject    Dim l_assembly, l_ClassName As String    'Acquires original URI    Dim originalURI As String = requestHeaders.Item("__RequestUri").ToString()        'Try to extract Assembly and Class Name    If IsPooledObjectURIFormat(originalURI, l_assembly, l_ClassName) = True Then


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist