Usando Singleton vs única chamada em .NET Remoting?

Question

Até este ponto toda a comunicação remota de código .NET que tenho escrito ou trabalhado com foi exposto como SingleCall.

deparei com um .NET componente comunicação remota hospedada em um serviço do Windows que é exposta como um Singleton.

Este objeto tem o potencial de ser chamado por mais de um cliente, ao mesmo tempo, e ele não tem fechaduras ou outras disposições para proteger seu estado interno.

Se eu entendi Singleton corretamente, então isso tem o potencial para grandes problemas corrigir?

Answer 1

Não há mais potencial do que um componente SingleCall. Ambos terão problemas se tentar acessar um local de memória compartilhada de forma insegura.

A diferença entre SingleCall e Singleton é que, para SingleCall, cada solicitação de entrada terá uma nova instância do tipo definido criado para lidar com essa chamada. Cada instância terá suas próprias variáveis ??espaço de memória e de instância, mas eles ainda podem estática compartilhar e variáveis ??globais, recursos externos, arquivos, conexões de rede, etc. Se a classe SingleCall é codificado para o acesso de qualquer estado compartilhado de memória de uma forma thread-inseguro , então você vai ter problemas.

A Singleton, por outro lado, só recebe uma instância criada para todas as solicitações recebidas, então, por definição, cada variável de instância em utilização nessa singleton é, de fato, compartilhada entre todos os pedidos recebidos. Um bom exemplo pode ser um publisher mensagem, que todo o código nas necessidades do servidor de acesso para enviar mensagens para um ou mais subscrito clientes ....

Para comentar endereço de @Cocowalla, certifique-se se você fizer isso, você substituir o método

  MarshalByRefObject.InitializeLifetimeService() 

como mostrado, ou o seu singleton vai morrer inesperadamente se ninguém chama isso por um tempo ...

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

Sim. Se os chamadores alterar o estado interno do objeto, e esses métodos não são thread-safe, então você é obrigado a entrar em apuros. Esse servidor deve ser single-chamada.

Mas, como ressalta Charles, se o objeto servidor acessa recursos partilhados (e qual servidor útil não?), Até mesmo servidores de chamada única pode entrar em apuros. Ainda assim, esses problemas são mais gerenciáveis. Acesso a um banco de dados, por exemplo, pode muito facilmente ser feitas transacional, e, portanto, seguro.

A linha inferior: ir para a chamada individual é uma simples e eficaz maneira de se livrar de 'metade' seus problemas. Cumpri-lo.