Singleton em Java App Servidor .. Quão ruim de uma idéia é essa?
https://stackoverflow.com/questions/660463
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Atualmente, estou trabalhando em algum código java mais antigo que foi desenvolvido sem servidores de aplicação em mente. É basicamente um grupo de "código caixa preta", com uma interface de entrada, e uma interface de saída. Tudo nas classes de "caixa preta" são estruturas de dados estáticos que contêm estado, que são colocadas através de algoritmos em intervalos de tempo (a cada 10 segundos). A caixa preta é iniciado a partir de um método principal.
Para evitar que isso fácil para mim, eu estou pensando em fazer a "caixa preta" um Singleton. Basicamente, qualquer pessoa que queira aceder ao interior lógica da caixa preta vai ter a mesma instância. Isto irá permitir-me a usar Mensagem Driven Beans como entrada para a caixa preta, e uma JMS Publisher de algum tipo como a saída da caixa preta.
Como ruim de uma idéia é essa? Alguma dica?
Uma das principais preocupações que tenho, porém, é que pode haver Threads no código "caixa preta" que eu ignoro.
Existe tal coisa como "escopo de aplicação objetos" em EJB?
Nota: eu estou usando Glassfish
Solução
Se você usar um singelton simples, você estará enfrentando problemas, uma vez que você entrar em um ambiente de cluster .
Em tal cenário, você tem vários carregadores de classe em vários JVMs, e seu padrão sinlgeton pausa como você vai ter várias instâncias dessa classe.
O uso somente aceitável para um singleton em um servidor de aplicativo (potencialmente em um ambiente de cluster) é quando você o singleton é totalmente state-menos, e é usada apenas como uma conveniência para acesso a dados / funções globais.
sugiro verificar solução de servidor do seu fornecedor da aplicação para este problema. A maioria, se não todos os fornecedores, fornecer alguma solução para as necessidades de seu tipo.
Especificamente para Glassfish, que você diz que você está usando, consulte a apoio Singleton EJB para Glassfish . Pode ser tão simples como adicionar uma única anotação.
Outras dicas
Eu diria que a criação de um singleton é realmente a idéia única viável. Assumindo que o código dentro desta "caixa preta" é conhecido por usar campos estáticos, é absolutamente inseguro para criar duas instâncias desse fachada. Os resultados são imprevisíveis contrário.
Longe de ser uma má idéia, ele realmente soa para mim como potencialmente muito a boa idéia.
Apenas a partir de um ponto de concepção do programa de vista: se a sua caixa preta é conceitualmente um "objeto" com propriedades e métodos que trabalhar com eles, em seguida, fazê-lo em um objeto, mesmo se não só vai sempre ser um deles instanciado .
Ele deve funcionar, mas há algumas questões que você pode ter que lidar com eles.
threading, como você mencionou. Um MDB é executado no container EJB, onde você não pode criar seus próprios tópicos, então você tem um problema potencial lá. Se você tiver acesso ao código real (que soa como você faz), você pode querer fazer alguma refatoração, quer eliminar os fios ou usar um "aprovado" método de segmentação. O CommonJ TimerManager provavelmente irá funcionar no seu caso declarado, uma vez que está realizando alguma tarefa em um intervalo. Existem implementações disponíveis para a maioria dos servidores de aplicação (WAS e Weblogic tê-lo incluído).
classloading - Esta é dependente de você configuração. Se o singleton é criada e manipulada de MDB de dentro do mesmo EAR, você vai ficar bem. do EAR separados significará diferentes carregadores de classe e várias instâncias de vocês Singleton. Não posso comentar sobre se isso seria um problema no seu caso ou não, sem mais informações.
Eu estou sentindo falta de um ponto? Você mencionou que o 'código caixa preta' contém Estado. MDBs pode ser limitada a 1 instância por destino, mas sem configuração adequada você vai acabar com algumas MDBs. Todos eles trabalhar com a sua única instância de 'código caixa preta'. Para mim parece que esta não é uma boa idéia, porque um feijão substituirá o estado 'código caixa preta' um outro feijão criou alguns carrapatos antes.
Parece-me que o artefato que melhor se adaptam à sua exigência é um JBoss MBean. (Se você está pensando em JBoss como AS candidato).
MBeans pode também ser implementado como Singleton, em caso de JBoss agrupamento.
Espero que isso é útil para você.
Rafa.
Corrigir o código para se livrar dos estática o mais rápido possível. Singletons não são um passo na direção certa -. Eles simplesmente adicionar desorientação adicional
Não use Singletons onde o estado pode mudar.
A exposição da instância global de sua classe caixa-preta não parece ser o caminho a percorrer. Muitas vezes, singletons vai parecer que eles vão facilitar as coisas para você, e de uma forma que podem, mas que muitas vezes volta a morder você e você acaba tendo que reestruturar um grande pedaço de seu código.
No mundo do servidor web, um objeto pode ser delimitada para o pedido, a sessão, ou o aplicativo. Talvez o que você precisa é um objecto de aplicação de escopo.
Pesquisar os docs para "aplicação escopo do objeto" ou "objeto vida aplicação".
Por que não criar uma interface de descanso para a coisa da caixa em branco e deixar os clientes a tomar http chamadas?
IMO, que é uma boa idéia ter um container EJB de suas necessidades Singleton. Em Java EE 6 colocando uma anotação @Singleton em seu bean de sessão dá-lhe um singleton chamado.
