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