[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_3-fcs/doc/Servlets5.html

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

http://java.sun.com/j2ee/tutorial/1_3-fcs/examples/src/web/bookstore1/database/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 :D
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 :D. 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 :D.

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]

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 :D.

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]

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. :D

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? :stordita:

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]

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

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? :stordita:

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 :D

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 :D

[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 :D. 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 :D.

[faretto]

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 :D

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 :D

infatti, prima di aver letto quanto scritto da PGI-bis, mi sarei aspettato di ottenere sempre come risultato "pippo", ma forse non e' cosi'.


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.


scusa se mi inserisco ancora, ma tu cosa intendi qui per "valore condiviso", visto che hai detto prima che ogni frame ha una propria copia delle variabili?

[PGI-Bis]

E' condiviso perchè tutti i Thread possono accedervi. Probabilmente sarebbe meglio "condivisibile" ma il termine delle specifiche è quello.

Attenzione a non cadere nell'eccesso opposto, cioè "se una cosa non è volatile allora questo codice non è thread-safe".

Le norme che stabiliscono cosa sia visibile e cosa non lo sia sono più d'una. Tendono anche al complicato ma è un complicato che, in un certo senso, semplifica.

Faccio un esempio.

class Pippo {
private String value = "hello";

public String getValue() {
return value;
}
}

public static void main(String[] args) {
final Pippo pippo = new Pippo();
new Thread() { public void run() {
String x = pippo.getValue();
}}.start();
}

Qui ci sono due Thread: il Main, che esegue l'inizializzazione di pippo e quindi l'assegnamento value = "hello", e un altro Thread che legge il valore del campo "value" dello stesso pippo.

Non c'è volatile, non c'è synchronized e tuttavia è garantito che il secondo Thread leggerà "hello". Lo è perchè c'è una regola che dice che l'azione che avvia un Thread è sincronizzata con la prima azione contenuta nel metodo run di quel Thread e c'è una regola che dice che le azioni in uno stesso Thread sono sincronizzate.

Insomma, c'è una sorta di rispetto dell'evidenza.

[faretto]

scusa se continuo a rompere, ma adesso mi si e' sollevato il dubbio e preferirei togliermelo. :stordita:
dal tuo discorso penso di aver capito che con "condiviso" tu intenda entita' esterne al metodo run, mentre prima pensavo tu ti riferissi a variabili locali del metodo run.
detto questo, non sono ancora sicuro di aver capito se il codice che ho postato prima sia un esempio corretto di quanto dicevi in precedenza. vedendo il caso che hai appena riportato, mi verrebbe da dire di si', ma se mi potessi dare la conferma sarebbe meglio :)

grazie mille e scusa ancora per il disturbo :ave:

[roby1483]

Adesso la cosa e' piu' chiara. Effettivamente e' giustissimo il discorso sul synchronized dei metodi ma segui questo esempio e la successiva domanda.
Io ho sempre la mia servlet fatta cosi:

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

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

public void servizioUno() {
ResultSet rs = null;
rs = db.executeQuery(...);

faccioQualcosa();

int esito = db.executeUpdate(...);

if(esito==1)
db.commit();
else
db.rollback();
}

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

Se ho due Thread che accedono contemporaneamente al metodo di servizio la sincronizzazione offerta dalla keyword "volatile" mi garantisce che se il primo Thread viene interrotto tra la select e l'update il secondo Thread non avra' accesso alla risorsa condivisa (DBHandler) fino a che il primo non avra' terminato di usare la risorsa? Se cosi' fosse come fa la JVM a capire questa cosa senza un blocco synchronized?

[PGI-Bis]

No.

Ricorda che un riferimento in Java è un puntatore. Cioè è una variabile che contiene un numero, null'altro. La "volatilità" si riferisce a quel numero. Volatile ti dice che se un thread cambia quel valore da 25 a 26 una successiva lettura vedrà 26. Trattandosi di puntatori, qui intendo 25 e 26 come indirizzi di memoria putativi.

Opera cioè rispetto al reindirizzamento del puntatore. Non esclude che due Thread possano leggere insieme quel valore. Poichè in Java la lettura di un puntatore avviene solo al fine di accedere ai metodi dell'oggetto puntato, ciò significa che, a prescindere dalla volatilità, due Thread possono invocare contemporaneamente uno stesso metodo di quel DBHandler.

Volatile non comporta mutua esclusione.

[roby1483]

Quindi a questo punto devo per forza mettere i metodi di servizio synchronized altrimenti posso avere accessi concorrenti alla connessione. O mi sbaglio anche stavolta?

[PGI-Bis]

E' giusto. E' una soluzione radicale, ma è giusto.

Ma se trasferisci la sincronizzazione ai metodi di DBHandler fai in modo che il codice eseguito in mutua esclusione sia solo quello che effettivamente interagisce con il database. Anche perchè immagino che il metodo di servizio non conterrà solo qualche invocazione ai metodi di DBHandler.

[PGI-Bis]

x faretto

Sottolineo che qualsiasi dubbio dovrebbe essere risolto facendo riferimento al capitolo 17.4 delle specifiche del linguaggio di programmazione Java.

I campi sono condivisi. Le variabili locali non sono condivise. Es:

public class Pippo {
private String campo = "ciccio";

public void metodo() {
String variabileLocale = "qualcosa";
}
}

"campo" è condiviso, nel senso che è memorizzato nella regione di memoria condivisa dai Thread (l'heap). Quando un Thread esegue un metodo che contiene un riferimento a campo, se quella è la prima volta che incontra campo, crea una copia locale di campo. Poi lavora su quella copia. In linea di principio, le modifiche che il Thread compie a quella copia non saranno mai scritte sulla variabile originale, quella che risiede nella memoria condivisa.

Il codice che hai incollato mi pare un po' strano perchè p è sempre null. Per un refuso, immagino.

Comunque, supponiamo che ci sia scritto "return (x = new Pippo())", cioè che il singleton sia creato "pigramente".

x potrebbe essere null. Non essendo volatile, il Thread che inizializza il singleton è libero di non scrivere mai sull'originale il valore "pippo".

Anche il singleton (p) potrebbe essere null.

[faretto]

perfetto, allora pare che abbia capito correttamente :)

ovviamente il codice era sbagliato, prima di postarlo l'ho modificato, e da bravo fesso ci ho piazzato un errore :doh: :asd:

grazie ancora per la disponibilita'

[roby1483]

Si e' vero pero' non sapendo come funziona internamente l'oggetto Connection ho pensato che se sincronizzo tutto il blocco fino al commit/rollback sicuramente i vari Thread non si influenzano tra di loro.
Se pero' mi dici che posso sincronizzare senza problemi i metodi di DBHandler lo faccio volentieri.
In DBHandler ho fondamentalmente questi due metodi:

public PreparedStatement getPreparedStatement(String sql) throws DBHandlerException {
PreparedStatement pst = null;
try {
pst = conn.prepareStatement(sql);
} catch (SQLException e) {
Logger.logError(this.getClass().toString(), "Impossibile recuperrare il PreparedStatement.");
throw new DBHandlerException("Impossibile recuperrare il PreparedStatement.");
}
return pst;
}


public ResultSet executeQuery(String sql) throws DBHandlerException {
ResultSet rs = null;
try {
rs = conn.createStatement().executeQuery(sql);
} catch (SQLException e) {
e.printStackTrace();
Logger.logError(this.getClass().toString(), "Impossibile eseguire la query.");
throw new DBHandlerException("Impossibile eseguire la query.");
}
return rs;
}

conn e' la variabile d'istanza della connessione aperta nel costruttore.
Dici che posso sincronizzare questi e lasciare i metodi di servizio della servlet non sincronizzati?

[PGI-Bis]

Guarda, la soluzione che adotterei io è creare un DAO, vale a dire un oggetto che astrae il concetto di base dati ed espone unicamente i metodi necessari alla specifica applicazione.

Ad esempio se le operazioni che devi fare sono salvare un Record, aggiornare un Record, eliminare un Record, cercare un Record, il DAO diventa una cosa tipo:

public class DAO {
public synchronized void open() {...}
public synchronized void close() {...}
public synchronized long saveRecord(RecordData r) {...}
public synchronized void updateRecord(long id, RecordData rd) {...}
public synchronized void deleteRecord(long id) {...}
public synchronized Collection<Record> findRecord(RecordData r) {...}
}

I dettagli relativi alla creazione ed all'esecuzione degli statement restano all'interno del DAO, così come privata è la gestione della connessione. La sincronizzazione esclude il concorso nell'esecuzione degli statement coi quali recuperi le informazioni dalla base dati.

Se prendi la connessione e gli tiri fuori un ResultSet tout-court altro non fai che spostare l'esigenza della mutua esclusione da DBHandler al codice che usa DBHandler perchè nè result-set nè statement sono di per sè adatti all'uso concorrente. Dobbiamo infatti ricordare che anche la scansione dei risultati contenuti in un ResultSet può tradursi nell'esecuzione di ulteriori operazioni sulla base dati.

D'altro canto la sincronizzazione è sufficiente per il primo metodo, quello che crea un PreparedStatement.

Insomma, si può fare anche così ma a me sembra più complicato rispetto al DAO "classico".

[roby1483]

Ti ringrazio davvero tanto per il tuo aiuto e la tua pazienza.