Singleton in Java App Server .. Che idea cattiva è?

Question

Attualmente sto lavorando su alcuni vecchi codici Java che sono stati sviluppati senza i server app in mente. È fondamentalmente un mucchio di & Quot; codice scatola nera & Quot; con un'interfaccia di input e un'interfaccia di output. Tutto nella & Quot; scatola nera & Quot; le classi sono Strutture dati statiche che contengono stato, che vengono inserite attraverso algoritmi a intervalli temporizzati (ogni 10 secondi). La scatola nera viene avviata da un metodo principale.

Per semplificarmi, sto pensando di creare " scatola nera " un Singleton. Fondamentalmente, chiunque voglia accedere alla logica all'interno della scatola nera otterrà la stessa istanza. Questo mi permetterà di usare i bean Message Driven come input per la black box e un editore JMS di qualche tipo come output della black box.

Quanto è cattiva un'idea questa? Qualche consiglio?

Una delle preoccupazioni principali che ho, è che potrebbero esserci discussioni nella " scatola nera " codice di cui non sono a conoscenza.

Esiste qualcosa come " oggetti con ambito applicativo " in EJB?

Nota: sto usando Glassfish

Answer 1

Se utilizzi un singolo singelton, incontrerai problemi una volta entrati in un ambiente cluster .

In tale scenario, hai più classloader su più JVM e il tuo pattern sinlgeton si interromperà poiché avrai diverse istanze di quella classe.

L'unico uso accettabile di un singleton in un server di app (potenzialmente in un ambiente cluster) è quando il singleton è totalmente privo di stato e viene utilizzato solo per comodità per accedere a dati / funzioni globali.

Suggerisco di verificare la soluzione del fornitore del server delle applicazioni per questo problema. La maggior parte, se non tutti i fornitori, forniscono una soluzione per i requisiti del tuo genere.

Specificamente per Glassfish, che dici di utilizzare, dai un'occhiata a Supporto Singleton EJB per Glassfish . Potrebbe essere semplice come aggiungere una singola annotazione.

Answer 2

Direi che la creazione di un singleton è in realtà l'unica idea praticabile. Supponendo che il codice all'interno di questo & Quot; scatola nera & Quot; è noto per l'utilizzo di campi statici, non è assolutamente sicuro creare due istanze di questa facciata. I risultati non sono prevedibili altrimenti.

Answer 3

Lungi dall'essere una cattiva idea, in realtà mi sembra una idea abbastanza buona .

Solo dal punto di vista della progettazione del programma: se la tua scatola nera è concettualmente un " oggetto " con proprietà e metodi che funzionano su di essi, quindi trasformalo in un oggetto, anche se ce ne sarà solo una istanza.

Answer 4

Dovrebbe funzionare, ma ci sono alcuni problemi che potresti dover affrontare.

Threading, come hai già detto. Un MDB viene eseguito nel contenitore EJB in cui non è possibile creare i propri thread, quindi esiste un potenziale problema. Se hai accesso al codice effettivo (che sembra che tu faccia), potresti voler fare un po 'di refactoring per eliminare i thread o usare un & Quot; approvato & Quot; metodo di threading. CommonJ TimerManager probabilmente funzionerà nel caso indicato poiché sta eseguendo alcune attività su un intervallo. Esistono implementazioni disponibili per la maggior parte dei server di app (WAS e Weblogic lo hanno incluso).

Classloading: dipende dalla tua configurazione. Se il singleton viene creato e manipolato da MDB all'interno dello stesso EAR, starai bene. Le EAR separate significheranno caricatori di classi diversi e istanze multiple di te Singleton. Non posso commentare se questo sarebbe un problema nel tuo caso o meno senza ulteriori informazioni.

Answer 5

Mi manca un punto? Hai detto che il "codice della scatola nera" contiene stato. Gli MDB possono essere limitati a 1 istanza per destinazione, ma senza una corretta configurazione si otterranno alcuni MDB. Tutti lavorano con la tua singola istanza di "codice black box". Per me sembra che questa non sia una buona idea, perché un bean sovrascriverà lo stato del "codice black box" che un altro bean ha già creato alcuni tick.

Answer 6

Mi sembra che il manufatto più adatto alle tue esigenze sia un MBean JBoss. (Se stai pensando a JBoss come candidato AS).

Esempio MBean standard

Gli MBean possono anche essere distribuiti come Singleton, in caso di clustering JBoss.

Clustering con JBoss

Spero che questo ti sia utile.

Rafa.

Answer 7

Correggi il codice per sbarazzarti delle statistiche il prima possibile. I singleton non sono un passo nella giusta direzione, ma aggiungono semplicemente ulteriori indicazioni errate.

Answer 8

Non usare i Singleton in cui lo stato può cambiare.

Esporre l'istanza globale della tua classe black-box non sembra la strada da percorrere. Spesso, i singoli sembrano sembrare che ti renderanno le cose più facili, e in un certo modo possono, ma spesso torna a morderti e finisci per dover ristrutturare una grande porzione del tuo codice.

Answer 9

Nel mondo del server web, un oggetto può essere impostato sulla richiesta, sulla sessione o sull'applicazione. Forse ciò di cui hai bisogno è un oggetto ambito di applicazione.

Cerca nei documenti " oggetto ambito applicazione " oppure " oggetto di durata applicazione " ;.

Answer 10

Perché non creare un'interfaccia di riposo per la cosa del riquadro vuoto e consentire ai clienti di effettuare chiamate http?

Answer 11

IMO, è una buona idea avere un contenitore EJB per le tue esigenze Singleton. In Java EE 6, inserendo un'annotazione @Singleton nel bean di sessione si ottiene un singleton denominato.