Using Singleton vs Single Call in .NET Remoting?

Question

Up until this point all the .NET remoting code I have written or worked with has been exposed as SingleCall.

I ran across a .NET remoting component hosted in a Windows service that is exposed as a Singleton.

This object has the potential to be called by more than one client at the same time, and it has no locks or other provisions to protect its internal state.

If I understand Singleton correctly then this has the potential for big problems correct?

Answer 1

No more potential than a Single call component. Both will have problems if they attempt to access a shared memory location in an unsafe manner. The difference between Single Call and Singleton is that for Single Call, every incoming request will get a new instance of the defined type created to handle that call. Each instance will in fact have it's own instance based stack and instance local variables, but they can still share static and global variables, external resources, files, network connections, etc. If the Single Call class is coded to access any shared memory state in a thread-UN safe manner, then you will have issues.

A Singleton otoh, only gets one instance created for ALL incoming requests, so by definition, every variable in use within that singleton is in fact shared among all incoming requests. A good example might be a message publisher, that all code in the server needs to access to send messages to one or more subscribed clients....
To address comment from @Cocowalla, make sure if you do this you override the method

  MarshalByRefObject.InitializeLifetimeService()

as shown, or your singleton will die out unexpectedly if noone calls it for a while...

public class MessageManager : MarshalByRefObject
{
    #region Singleton / MarshalByRefObject code        
    private static MessageManager mgr = 
        new MessageManager(); // creates singleton 
    static MessageManager() { }
    private MessageManager() { }
    public static MessageManager Instance { get { return mgr;  } }
    public override object InitializeLifetimeService() { return (null); }
    #endregion Singlelton code
    // ... other stuff ... 
 }

  // in Remoting Host initialization code...      
   MessageManager mgr = MessageManager.Instance; // generates singleton;
   RemotingServices.Marshal(mgr, URI);

Answer 2

Yes. If the callers alter the object's internal state, and those methods are not thread-safe, then you're bound to get into trouble. That server should be single-call.

But as Charles points out, if the server object accesses shared resources (and what useful server doesn't?), even single-call servers can get into trouble. Still, those problems are more manageable. Access to a database, for example, can quite easily be made transactional, and hence safe.

Bottom line: going for single-call is a simple and effective way of getting rid of 'half' your troubles. Stick to it.