[Java Servlet] quante istanze ci sono?

[roby1483]

Salve a tutti,
sto' facendo un progettino con Google Web Toolkit, che per la parte server usa delle servlet. Non conoscendo molto bene le servlet mi sorge spontanea una domanda, quante volte viene istanziata la servlet? Una sola volta all'avvio di Tomcat? Una volta alla creazione di ogni sessione? Ogni volta che viene fatta una richiesta? Nel caso ci sia solo un'istanza come vengono gestite eventuali richieste concorrenti?
Altra cosa, se c'e' una sola istanza che viene mantenuta per tutta la durata dell'applicazione e' corretto creare la connessione al db nel costruttore e tenerla aperta oppure e' meglio aprirla e chiuderla ad ogni richiesta?

Grazie a tutti.

[PGI-Bis]

La questione è trattata nel capitolo SRV2.2 delle specifiche servlet.

L'istanza è unica a meno che l'ambiente non sia distribuito (cioè il carico di lavoro è distribuito tra più JVM) o la classe servlet estenda SingleThreadModel (approccio sconsigliato).

La creazione della servlet può avvenire all'avvio del server o può essere posticipato all'intervento della prima richiesta (la scelta spetta al server).

Le richieste concorrenti sono gestite tramite esecuzione concorrente dei metodi di servizio dell'istanza della servlet. Detto altrimenti, è possibile che in uno stesso istante cento thread eseguano lo stesso metodo doGet. Per come funziona il linguaggio di programmazione Java ciò significa che ognuno dei cento Thread lavorerà su una propria copia di quel metodo doGet.

Per la gestione di risorse locali, dove la località è qui intesa come pertinenza al ciclo di vita della servlet, esistono i metodi init() e destroy(). Il metodo init() è invocato dopo la costruzione dell'istanza e prima che l'istanza sia posta in servizio. Il metodo destroy() è invocato quando la servlet viene ritirata dal servizio. Occorre tener presente che l'uso di risorse il cui ambito sia esterno al metodo di servizio della servlet deve essere predisposto all'accesso concorrente (il metodo di servizio può essere eseguito da più di un Thread in uno stesso istante, la connessione è, in quanto campo, condivisa da tutti questi Thread, ergo sorge un problema di regolamentazione d'uso della connessione).

[roby1483]

Grazie mille, sei stato molto chiaro nella prima parte ma nella seconda mi sono perso un po'.
Vediamo se ho capito bene, per essere sicuro di non aver problemi con la connessione al db mi conviene crearla e chiuderla dentro al doGet() cosi' che anche se ho 2 thread che eseguono il doGet() nello stesso momento uno dei due puo' chiamare il metodo rollback() sulla propria connessione senza interferire sull'atra. Ho capito bene?

[PGI-Bis]

La connessione è un caso di risorsa esterna non predisposta all'uso concorrente.

Creandola nel metodo di servizio della servlet sei certo che ognuno dei potenziali Thread disporrà di un riferimento Connection unico e proprio.

Tuttavia quelle connessioni sono tutte connessioni alla stessa base dati.

Per la connessione ad una base dati, quindi, il problema non è tanto quello di avere o non avere un riferimento condiviso tra più Thread quanto quello di garantire l'atomicità delle mutazioni subite dalla base dati.

E qui entrano in gioco le transazioni. Una soluzione al problema è pertanto:

condividere connessione inizializzandola nel metodo init() e liberandola nel metodo destroy() della servlet;
garantire l'atomicità delle operazioni sulla base dati attraverso l'uso delle transazioni;

[roby1483]

Quindi non importa che metta il metodo synchronized perche' tanto anche se ho una sola connessione (variabile d'istanza inizializzata nel metodo init()) ogni query viene eseguita su un diverso statement, giusto?

[PGI-Bis]

Nain. Devi sincronizzare comunque perchè la connessione non è un oggetto che puoi far usare a più thread. In più devi usare le transazioni perchè quello che i metodi della connessione fanno (inclusi i metodi dei derivati della connessione) non è compatibile con un contesto concorrente.

E' come se ci fossere due livelli. Il primo è quello della sincronizzazione Java che devi naturalmente usare per le chiare conseguenze che hanno.

Questo:

Connection conn = database.apriConnessione();

non va bene se "conn" è un campo che sarà usato da più thread. Deve essere:

volatile Connection conn = ...

oppure

final AtomicReference<Connection> conn = new AtomicReference<Connection>(database.apriConnessione());

oppure:

Connection conn;

private synchronized void initializeConnection() {
    conn = ...
}

E questo lo devi fare per poter semplicemente dire "in Java conn è una variabile che posso far usare a più Thread".

In più c'è il problema della molteplicità di utenti della base dati. Le transazioni proteggono l'integrità della base dati in due modi. Garantendo che i dati siano integri in sè e garantendo che le mutazioni siano sempre interamente visibili o interamente invisibili.

Qui c'è un esempio:

http://java.sun.com/j2ee/tutorial/1_...Servlets5.html

qui il codice sorgente del "DAO" usato da quell'esempio:

http://java.sun.com/j2ee/tutorial/1_...se/BookDB.java

Ma è solo una possibile soluzione. Una volta stabilito che la connessione deve essere thread-safe, per via del linguaggio, e le mutazioni transazionali, per via del funzionamento della base dati, sei libero di scegliere se accedere direttamente alla connessione, come fa quell'esempio, oppure creare un servizio parallelo di accesso ai dati, ad esempio attraverso una coda concorrente di eventi.

Ripeto, sincronizzazione per questioni materiali di linguaggio, transazione per motivi logici di interazione con la base dati.

[roby1483]

Nel caso della servlet pero' sono sicuro che il metodo init() viene eseguito una sola volta quindi posso inizializzare la connessione li' dentro senza dover mettere init() stesso synchronized.
Poi mettendo "synchronized void doGet(...)" dovrei risolvere.
Io uso una classe che ho chiamato DBHandler per l'interazione con il db quindi non uso direttamente la connessione nelle servlet ma appunto un'istanza di DBHandler (che implementa la gestione delle transazioni con commit e rollback), la mia servlet diventa tipo questa:

public class MiaServlet extends HttpServlet {
   private DBHandler db = null;

   public void init() {
      db = new DBHandler(...);
   }

   public synchronizrd void doGet(...) {
      // Uso il DBHandler
   }

   public void destroy() {
      db.close();
   }
}

A questo punto dovrei mettere la variabile db "volatile" visto che comunque al suo interno usa una connessione?

Grazie mille.

[PGI-Bis]

Nain. Non è sufficiente che una cosa sia eseguita una sola volta affinchè essa sia anche "thread safe".

Prendiamo il caso che esponi.

DBHandler è inizializzato a null da un certo Thread.

Nel metodo init() un Thread assegna a "db" un certo valore. Secondo le specifiche del linguaggio, tale assegnamento è visibile solo al Thread che abbia eseguito l'assegnamento.

Esistono poi altre condizioni in presenza delle quali questo assegnamento risulta visibile ma non si applicano al nostro caso.

doGet, che non devi sincronizzare, viene eseguita da un certo Thread. Se quel Thread è diverso da quello che ha assegnato il valore a DB allora non è garantito che questo Thread acceda ad un valore diverso da null.

Per questa ragione renderesti "db" volatile: perchè "volatile" significa che la lettura del valore di quella variabile è sempre coordinata con una precedente scrittura. Ergo, se init() scrive "db = qualcosa", essendo db volatile e capitando doGet dopo init, nel doGet db varrà "qualcosa".

[roby1483]

Non ci sto' capendo piu' niente, non e' che prima ci capissi di piu' comunque
Mi sono anche tirato da solo la zappa sui piedi perche' ho tirato in ballo il metodo doGet(...) che nelle servlet di GWT non e' visibile. Mi spiego meglio, perche' detto cosi' potrebbe sembrare un'eresia . Le classi lato server di GWT, quelle che mettono a disposizione i servizi richiamati dal browser in maniera asincrona, estendono la classe RemoteServiceServlet che a sua volta eredita da HttpServlet quindi nelle classi che scrivo io il metodo doGet(...) non viene riscritto. Detto questo nella mia servlet avro' tanti metodi quanti sono i servizi da richiamare ma non avro' il metodo doGet.
La mia servlet di partenza, senza volatile o synchronized, quindi e' questa:

public class MiaClasseServizio extends RemoteServiceServlet {
   private DBHandler db = null;

   public void init() {
      db = new DBHandler(...);
   }

   public int getNumero() {
      // Uso il DBHandler
   }

   public void destroy() {
      db.close();
   }
}

A questo punto come devo mettere i vari synchronized e volatile?

[PGI-Bis]

doGet è per dire "il metodo di servizio". Una servlet ha tre categorie di metodi: crea, ammazza e fai qualcosa. doGet, per una servlet http, appartiene alla terza categoria. Più in generale, sono i metodi service che fanno qualcosa.

Come modificare quella classe:

private final AtomicReference<DBHandler> db = new AtomicReference<DBHandler>();

E' come dire:

private volatile DBHandler db = null;

ma fa più fico .

Nell'init scriverai:

db.set(new DBHandler(...));

In destroy() scriverai;

db.get().close();

DBHandler sarà usata in un contesto concorrente. Così come è necessario rispettare i vincoli di concorrenza imposti dal linguaggio per db, così dovrai fare per il contenuto di DBHandler.

synchronized, volatil, AtomicXXX, Lock, Condition e compagnia bella, sono, per certi aspetti, alternativi.

Vale a dire, che quello che su abbiamo fatto con Atomic, si sarebbe potuto fare anche con synchronized. In un modo diverso, con conseguenze diverse (ad esempio volatile e AtomicXXX si applicano ad una variabile, synchronized di applica ad un blocco di codice, ergo con synchronized posso rendere thread-safe cose che non siano dichiarazioni di variabili).

Tutto qua. La concorrenza è di per sè una questione elementare. In Java lo è anche di più.

[roby1483]

Originariamente inviato da PGI-Bis

DBHandler sarà usata in un contesto concorrente. Così come è necessario rispettare i vincoli di concorrenza imposti dal linguaggio per db, così dovrai fare per il contenuto di DBHandler.

Cioe' dentro la classe DBHandler devo mettere volatile o AtomicXXX alla connessione? Ma mettere il lock all'oggetto che contiene la connessione non e' sufficiente a far si che non ci siano accessi in contemporanea alla connessione stessa?

[PGI-Bis]

Il blocco sincronizzato esclude che due thread eseguano lo stesso blocco contemporaneamente. Il problema della sufficienza è un altro.

Prendi un qualsiasi assegnamento ad un campo ed il relativo getter:

class Pippo {
    private Object x = "qualcosa";

    public Object getX() {
        return x;
    }
}

E' roba da settimana enigmistica: quanto vale "getX()"? Vale "qualcosa" se il Thread che invoca getX() è lo stesso che ha eseguito l'assegnamento durante l'inizializzazione. Se l'oggetto è creato da un Thread e getX è invocato da un altro Thread allora getX() può restituire "qualcosa" oppure null.

La parola chiave volatile, come gli AtomicReference, spezzano quest'incertezza e dicono che getX vale sempre "qualcosa".

private volatile Object x = "qualcosa";

Lo stesso fa il blocco sincronizzato. Cioè oltre alla faccenda della mutua esclusione, il blocco sincronizzato fa anche sì che le scritture che avvengono all'interno di un blocco sincronizzato siano sempre leggibili in altri blocchi sincronizzati (sullo stesso monitor).

public class Pippo {
    private Object x;
    {
        synchronized(this) {
           x = "qualcosa";
        }
    }

    public synchronized Object getX() {
        return x;
    }
}

Si nota il punto? La concorrenza non è solo un problema di mutua esclusione all'accesso ma anche di visibilità di certe operazioni eseguite da Thread diversi.

[roby1483]

Cavolo quando ho fatto il laboratorio di programmazione concorrente all'Universita' le cose mi sembravano molto piu' semplici, questo discorso della visibilita' delle variabili non mi sembra di averlo mai sentito.
Comunque credo che continui a sfuggirmi qualcosa sulla questione della sufficienza. Ho compreso l'importanza di "volatile" (o del piu' esotico AtomicReference) pero' non riesco a capire se questa cosa la devo propagare anche dentro l'oggetto DBHandler. Il mio ragionamento mi dice di no ma visto che i fatti dimostrano che c'ho capito poco...
Questo fatto della keyword volatile si applica a tutti i tipi di dato, anche quelli primitivi?

Ho cercato i sorgenti del laboratorio di programmazione concorrente ma non li ho trovati pero' mi ricordo che c'era sempre un monitor con le risorse condivise (ma senza volatile) e poi una serie di metodi synchronized che i vari Thread richiamavano per l'accesso esclusivo alle risorse. Non mi ricordo pero' se il monitor era una classe statica o veniva istanziata nel metodo main.

[PGI-Bis]

Volatile si applica a tutti i campi, primitivi o meno. Tutto è dettagliatamente documentato nel capitolo 17.4 delle specifiche del linguaggio di programmazione Java.

Il monitor che avete studiato sarà stato con ogni probabilità il monitor in quanto primitiva della programmazione concorrente (come i semafori, i mutex e via dicendo).

Il monitor che abbiamo sottointeso qui è quella stessa primitiva ma nella sua versione "built-in" che, in Java, è associata ad ogni istanza di Object (ogni istanza ha il suo monitor).

Il profilo concorrente del linguaggio di programmazione Java si risolve semplicemente in due parti: la mutua esclusione, determinata dai blocchi sincronizzati, e l'ordine di esecuzione, determinato da un ristretto insieme di regole in cui rientrano i blocchi sincronizzati, il modificatore volatile, il modificatore final, l'avvio di un Thread e l'ordine delle istruzioni così come appare nel codice sorgente.

[roby1483]

Quindi per il fatto che ogni istanza e' monitor di se stessa non c'e' bisogno di mettere i metodi synchronized per la mutua esclusione?
Scusa la domanda ma cos'e' che fa di questo monitor la versione "built-in"?

[PGI-Bis]

Non arrotolarti .

Ogni oggetto è (ha) un monitor perchè suonava bene quando crearono il linguaggio. Il nuovo package concurrent dice che oggi non suona più tanto bene.

Il monitor built-in esclude che due Thread possano eseguire un blocco di codice insieme. E' un monitor normale.

[faretto]

Originariamente inviato da PGI-Bis

Il blocco sincronizzato esclude che due thread eseguano lo stesso blocco contemporaneamente. Il problema della sufficienza è un altro.

Prendi un qualsiasi assegnamento ad un campo ed il relativo getter:

class Pippo {
    private Object x = "qualcosa";

    public Object getX() {
        return x;
    }
}

E' roba da settimana enigmistica: quanto vale "getX()"? Vale "qualcosa" se il Thread che invoca getX() è lo stesso che ha eseguito l'assegnamento durante l'inizializzazione. Se l'oggetto è creato da un Thread e getX è invocato da un altro Thread allora getX() può restituire "qualcosa" oppure null.

scusate se mi intrometto nella discussione, ma sarei abbastanza interessato a campire in maniera corretta questo punto del funzionamento della concorrenza.

in riferimento alla parte quotata, vorrei sapere se ho capito correttamente quello che intendi dire. Secondo l'idea che mi sono fatto, a partire dalla tua classe, vorrebbe dire che il seguente codice:

public class Prova implements Runnable{

	public void run() {
		Pippo p =Pippo.getInstance();
		
		if(p.getX()==null){
			System.out.println("p.get = "+p.getX());
		}		
	}

	public static void main(String[] args) {
		Thread[] threads = new Thread[100];
		for (int i = 0; i < threads.length; i++) {
			threads[i] = new Thread(new Prova());
			threads[i].start();
		}
	}
}

public class Pippo {
	private String x = "pippo";	
	private static Pippo p=null;
	
	private Pippo(){}

	public String getX() {
		return x;
	}
	
	public static Pippo getInstance(){
		if(p==null){
			return new Pippo();
		}else{
			return p;
		}
	}
}

potrebbe presentare dei casi in cui il valore di p.getX e' null.
ho capito correttamente?

il singleton mi sembra soddisfare la richiesta

Se l'oggetto è creato da un Thread e getX è invocato da un altro Thread

sinceramente non sono per niente convinto di aver capito bene, ma non mi viene in mente nessuna altra interpretazione.
grazie per le eventuali risposte

[roby1483]

Originariamente inviato da faretto

scusate se mi intrometto nella discussione, ma sarei abbastanza interessato a campire in maniera corretta questo punto del funzionamento della concorrenza.

in riferimento alla parte quotata, vorrei sapere se ho capito correttamente quello che intendi dire. Secondo l'idea che mi sono fatto, a partire dalla tua classe, vorrebbe dire che il seguente codice:

public class Prova implements Runnable{

	public void run() {
		Pippo p =Pippo.getInstance();
		
		if(p.getX()==null){
			System.out.println("p.get = "+p.getX());
		}		
	}

	public static void main(String[] args) {
		Thread[] threads = new Thread[100];
		for (int i = 0; i < threads.length; i++) {
			threads[i] = new Thread(new Prova());
			threads[i].start();
		}
	}
}

public class Pippo {
	private String x = "pippo";	
	private static Pippo p=null;
	
	private Pippo(){}

	public String getX() {
		return x;
	}
	
	public static Pippo getInstance(){
		if(p==null){
			return new Pippo();
		}else{
			return p;
		}
	}
}

potrebbe presentare dei casi in cui il valore di p.getX e' null.
ho capito correttamente?

il singleton mi sembra soddisfare la richiesta


sinceramente non sono per niente convinto di aver capito bene, ma non mi viene in mente nessuna altra interpretazione.
grazie per le eventuali risposte

In realta' credo che in questo caso ritorni sempre null perche' p non viene mai inizializzato a qualcosa di diverso.
Ma aspetta che ti risponda PGI-Bis perche' come puoi vedere dai miei post non c'ho capito molto neanche io

EDIT:
Credo di aver detto una cavolata.
Credo che getX non ritorni mai null perche' quando p e' null ritorni una nuova istanza di Pippo che avra' x="pippo".

Ma anche questo non prenderlo per oro colato, mi sto' intrippando il cervello con questa concorrenza

[roby1483]

PGI-Bis, apprezzo molto la tua disponibilita' e spero che tu non te la prenda ma ancora non c'ho capito molto.
La parola chiave "volatile" garantisce che la variabile abbia lo stesso valore per tutti i Thread pero' non e' un meccanismo di sincronizzazione, non mi garantisce che non ci siano due accessi concorrenti alla variabile o sbaglio?
Se metto synchronized ai metodi di servizio cosa succede? e' un errore? Perche' istintivamente mi verrebbe da metterli appunto per avere la garanzia che non ci siano accessi concorrenti alla variabile condivisa (DBHandler).
Devo modificare anche la classe DBHandler e mettere qualcosa di sincronizzato o di volatile anche li' dentro? Seguendo il mio ragionamento istintivo di prima direi di no perche' mettendo sincronizzati i metodi di servizio ho gia' evitato accessi concorrenti alla variabile condivisa, ma anche questa volta, come al solito, potrei sbagliarmi.
Spero che tu trovi la pazienza di rispondere anche a queste mie altre domande.

Grazie infinite.

[PGI-Bis]

L'accesso concorrente alla variabile, se intendo correttamente, è sempre escluso. Nel senso che ad eccezione di long e double, non è consentito il caso in cui un Thread legga un pezzo di una variabile mentre un altro ci scrive sopra.

Sembra che questo sia il mese della concorrenza . L'ho scritto in un altro post.

L'unità di esecuzione dei Thread è il "frame". Il frame è una struttura dati che contiene le istruzioni necessarie all'esecuzione del codice contenuto in un metodo e contiene una copia delle variabili usate in quel codice (parametri, variabili locali, campi). Cioè i Thread operano su copie private delle variabili che scriviamo nel codice. Esempio:

public class Pippo {
    private int x;

    public void faiQualcosa() {
        x = 5;
    }
}

Quando invoco faiQualcosa dietro le quinte viene creato un frame che rappresenta il metodo faiQualcosa. In questo frame si trovano delle copie delle variabili usate in quel metodo. Nel nostro caso il frame conterrà una copia del campo "x". Il Thread lavora su questa copia. Quando legge non legge il valore del campo x di Pippo ma il valore della copia del campo x. Quando scrive non scrive sull'x di Pippo ma sul proprio x.

E qui si capisce l'inghippo. Credo. Se ogni Thread lavora su copie personali dei campi, le operazioni che i Thread compiono su quelle copie non interferiscono le une con le altre. Se il Thread A scrive 5 sulla propria copia privata di x, il Thread B, che ha a sua volta una copia di x, quando legge x non vedrà il valore scritto dal Thread A, perchè A e B scrivono e leggono su variabili che sono in realtà diverse.

Sul fatto che volatile sia anche un meccanismo di sincronizzazione, la risposta è sì ma la ragione è fuorviante rispetto al topic. E' un meccanismo di sincronizzazione perchè la sincronizzazione è una corrispondenza tra l'ordine di esecuzione di un insieme di istruzioni in un flusso sequenziale e l'ordine di esecuzione delle stesse istruzioni in flussi paralleli e volatile fissa un ordine tra la lettura e la scrittura di un campo. Ma non credo che sia questo ciò che ti interessa sapere.

L'apposizione del modificatore synchronized esclude che due Thread possano eseguire in concorso il metodo marcato synchronized. Ha anche un effetto simil-volatile, cioè se un Thread scrive un valore in un campo all'interno di un blocco sincronizzato deve anche aggiornare il corrispondente valore condiviso.

Ciò detto, il problema è che marcando il metodo di servizio come synchronized escludiamo in radice la possibilità che il server sfrutti il parallelismo per rispondere agilmente alle richieste proveniente da più client.

Supponiamo ad esempio che il tempo di esecuzione del metodo di servizio sia di un secondo. Cosa succede se dieci client accedono al servizio? Nel modello normale, ogni client avrà una risposta da parte di un Thread diverso e il tempo di esecuzione per ogni client sarà di circa un secondo. Nel modello sincronizzato, il tempo di risposta è una funzione dell'ordine di servizio. Il primo client servito avrà una risposta in un secondo, il secondo in due, il terzo in tre... eccetera.

La domanda è: c'è un'alternativa migliore? Dipende. Se il tempo di risposta è interamente consumato dall'accesso alla base dati allora la risposta è no. La base dati è una, i client sono tanti, si attaccano. Ma se al tempo di risposta contribuisse in modo rilevante l'esecuzione di un pezzo del metodo di servizio che potresti rendere tranquillamente parallelo, allora anzichè escludere l'accesso concorrente a tutto quanto il metodo di servizio potresti limitare l'esclusione al solo accesso alla base dati.

L'esempio di Sun riportato all'inizio, quando rende mutualmente esclusivo l'accesso alla sola base dati, anzichè sincronizzare il metodo di servizio, fa proprio questo: limita la parte di codice necessariamente sequenziale all'accesso al database perchè il resto del metodo di servizio della servlet costruisce una pagina html con valori locali immutabili.

Non vado oltre perchè ho già scritto una prosopopea .