I have a WCF, tcp-based client server application (self-hosted) in which communication occurs via callbacks and InstanceContextMode is PerSession. I want to provide an Admin interface to this app which would allow an administrator to view details of all the connected users and provide a degree of administrative control (for example forcibly disconnecting a session).
Since I'm using callbacks, each client proxy gives the server its instance context via the constructor. For example, the client instantiates its proxy to the server using:
public class ClientCallbackHandler : IMyServerCallback
{
proxy = new MyServiceClient(new InstanceContext(this));
At the server side I retrieve this context using:
var currenContext = OperationContext.Current;
My initial thoughts were to implement a singleton 'SessionAdmin' class which maintains a collection of OperationContext objects (i.e. - holds a reference to the context of each connected client). Every new client session would register with the same instance of the 'SessionAdmin' class, thereby providing a central class which has access to all client sessions.
This works to a degree, but at various points when I access my collection of 'OperationContext' objects to get a clients details or perform some other operation I notice that the context is throwing 'Object disposed' exceptions.
My question is firstly, does the above sound like a reasonable way of providing server-side administrative control over WCF sessions? If so, how can I maintain a collection of client sessions or their contexts on the server-side without those objects being disposed? An example of the problem is:
foreach(var context in MyContextCollection)
{
DisplayClientDetails(context);
...
}
public void DisplayClientDetails(OperationContext context)
{
var sessionID = context.SessionId; //No problem here
var user = context.ServiceSecurityContext.PrimaryIdentity.Name; //ServiceSecurityContext has been disposed