Con 2 server Web, una classe singleton avrà 2 istanze?

Question

Con 2 server Web, una classe singleton avrà 2 istanze?

Answer 1

Entrambi i server Web avranno istanze separate dei loro processi di applicazione sia .net o java. Quindi Sì, entrambi i server avranno le loro singole istanze della classe singleton.

Indipendentemente dal fatto che questi due server Web siano due macchine fisiche diverse, anche se si trovano sullo stesso server, funzioneranno sicuramente su processi diversi. Ogni processo caricherà i suoi oggetti in memoria separatamente da qualsiasi altro processo.

specifically in case of asp.net - Anche nel singolo server Web, ogni sito causerà un'istanza separata della classe Singleton. Poiché ogni sito nel processo di lavoro di asp.net viene caricato in un dominio dell'applicazione separato, non è possibile che due domini interferiscano tra gli oggetti degli altri. Quindi, in caso di asp.net, anche il singolo server web con un singolo processo di lavoro asp.net può/avrà più istanze della classe singleton separate ciascuna da un'altra.

Answer 2

Sì, si dispone di un Singleton per ogni JVM e anche di caricatori di classe.

Vedere questo articolo When is a Singleton not a Singleton? (per Java).

Answer 3

Cosa intendi per "2 server Web"? Il campo statico (in singleton) è limitato al dominio dell'applicazione (in .net).

Quindi, se i due server Web vengono eseguiti in due domini dell'applicazione separati, quindi sì, altrimenti no.

Answer 4

In effetti si potrebbero avere 2 istanze di chiamate singleton in UN server Web, se la sua parte di una webapp viene distribuita due volte.

In Java, il classloader fa parte dell'identità di una classe. Puoi caricare la stessa classe due volte con diversi programmi di caricamento classi e tutti i campi statici esisteranno due volte. C# ha un meccanismo simile.

Answer 5

Come un'estensione di questa domanda, in particolare per le applicazioni Web .NET, è necessario prestare attenzione alla gestione di SessionState. Supponendo che le sessioni non siano "appiccicose" (l'utente rimane su un server Web una volta stabilita la sessione), è necessario modificare SessionState in out-of-process. Questo può essere il server di stato della sessione ASP.NET o SQL Server, ma il punto chiave da ricordare è che SessionState non viene condiviso automaticamente tra i server, a meno che non venga reso condiviso da out-of-process. Inoltre, tutto ciò che inserisci in SessionState deve essere serializzabile; aggiungi l'attributo [Serializable] a qualsiasi classe che usi in SessionState.

Answer 6

È possibile creare un server Web che eseguirà il multiplex su tutto: connessioni, socket di ascolto e persino interfacce. Rimarrà ancora un'istanza della classe, solo un thread, e per di più un footprint di memoria piuttosto piccolo. L'avvertenza è che, mentre dalla maggior parte dei punti di vista pratici assomiglierà a due server, sarà sempre un solo server (e se si blocca, si blocca tutto ...)

Questo approccio non è così popolare come multi Tuttavia, poiché è più leggero sull'hardware, è più difficile da gestire per lo sviluppatore: è necessario moltiplicare esplicitamente ogni cosa e destreggiarsi tra tutte le connessioni nelle chiamate non bloccanti. Se si generano alcuni thread aggiuntivi, il sistema operativo richiede molto lavoro da parte dell'utente, consentendo di scrivere un server più ricco di funzionalità più semplice.

Ovviamente anche in una generazione di server con un singolo thread di un secondo server in un'attività separata è ancora possibile, solo dall'utente/amministratore/chi esegue di nuovo il file binario, con configurazione diversa. Ci vuole una programmazione piuttosto elaborata per evitare che ciò accada.

Answer 7

Ecco perché JSP/Servlet fornisce l'idea di "sessione" e dati "applicazione". Questi dovrebbero essere condivisi tra i server in un ambiente multi-server.