Newsgroup: it.comp.java
Titolo: dubbi servlet e esecuzione concorrente

salve,
dunque m stoavvicinando alla pratica (la teoria l'ho accquisita) del
mondo j2ee servlet/jsp e incomincio ad avere qche dubbietto:
-1-Una volta istanziate e inizializzate le servlet sono in ascolto
delle richieste (get,post,head..)
-2-Se arriva una richiesta essa è gestita in un nuovo thread
innanzitutto mki sfugge esattamente quali siano i pezzi di codice che
vengono messi in thread concorrenti (il metodo service?, il metdo Doget
chiamato? il metodo Dopost chiamato?)
Dunque i metodi doxxx (che saranno nel thread sicuramente eprchè
implemenato la logica applicativa)non sono sincornizzati allorchè
possono alternarsi nell'esecuzione..
allora mi domando ma istruzioni di input/output della servlet tipo
seguente entro a un metodo doXXX  (le variabili sono locali al metodo):
....
string b=req.getParameter("b")
Printwriter a =res.getWriter()
....
sono influenzate dal multithreading e vanno gestite? (ovvero il valore
di req res a e b viene sovrascritto passando l'esecuzione da un thread
all'altro)
per l'acceso a database con jdbc l'oggetto connessione è otenuto con
metodui getConnection(... ...) sul drivemanager, questi metodi
richiamano un metodo synchronize connect() del drive jdbc specifico
dunque nessun thread della stessa applicazione può usarlo
contemporaneamente..
Per gestire letture/scritture da db in muta esclusione mettereste
l'istruzione geconnection nel metdo doxxx e quele di nizializzazione
del driver nel metodo init è una soluzione dignitosa?
Leggevo inoltre che di norma jdbc fa autocommit ... ...se ho capito
giusto per transazioni complesse è necessario disbilitarlo ai fini
della mutua esclusione (di accesso db da servlet)
oltre a ciò di cui gia fatto sopra...
grazie a tutti

amntcx ha scritto:
sto pian piano trovando qke risposta ai miei dubbi
variabili locali, parametri dei metodi sono thread-safe e gli
HttpServletRequest, HttpServletResponse sono thread-safe cioè creti
per ongi richiesta.
ciò che dovrebbe essere controllato sono:
variabili statiche
variabili di istanza
(della classe servlet)
a ciò è anche necessario sincronizzare  lo stato della sessione
(evitare interfogliamento di read/write da parte dello stesso cleint
attraverso servlet sullo'oggetto Httpsession)
e anche servletcontext..
per l'accesso al db ci sto ancora meditando
consiglio questo free e-book che mi ha chiarito i dubbietti:
http://www.theserverside.com/tt/books/addisonwesley/ServletsJSP/index.tss

 variabili di istanza
Non si dovrebbero usare variabili di istanza... c'era un thread 
sull'argomento tempo fa. Alcuni servlet-engine (o tutti, non mi ricordo 
mai se è proprio una specifica) usano una sola istanza della servlet per 
tutte le richieste, per cui le variabili statiche e quelle di istanza in 
pratica si equivalgono! In ogni caso, anche se non ne usassero una sola, 
non hai mai il controllo su quale istanza stai usando per cui il 
discorso vale lo stesso.
Per la questione db, non vorrei dire castronate, ma più che dalla 
servlet, credo dipenda da dove ottieni le connessioni (ovvero se ti 
arrivano thread-safe); ma è molto che non uso connessioni a livello 
jsp/servlet per cui ho le idee un pò arrugginite.
bye
DKano

 jsp/servlet per cui ho le idee un pò arrugginite.
Ripensandoci, mi sa che ho detto una stupidata; una volta che la tua 
connessione la metti nella session o in una var locale non ci dovrebbero 
esser problemi ulteriori... ma ripeto il concetto sulla ruggine:-)
bye
DKano

 esser problemi ulteriori... ma ripeto il concetto sulla ruggine:-)
..dunque per variabili statiche o di istanza nn prevedevo di usarne cmq
casomai si egstisce l'acesso in muta esclusione...(idem per le altre
risosorse citate prima..)
per il db (codice dentro a un metodo doXXX):
connection conn = drivermanager.getConnection(... , .. , ..,)
l'oggetto connection può essere di un thread alla volta della stessa
applicazione perchè il metodo getConnection richiama un metodo
"connect()" del driver caricato che è sincronized quindi mettendo il
caricamento del driver nel'init e la conection nei metodi non dovrei
avere problemi...
ivece.. ..non ho ancora chiaro il discorso del commit/autocommit su
come può influenzare la mutua esclusione per l'accesso al db..

 
Stai parlando del livello di isolamento del db? Quello dipende da come 
imposti la connessione, piů che dai Thread. Ovverosia, anche due 
connessioni indipendenti, se imposti un certo livello di isolamento non 
potranno accedere contemporaneamente ai dati... perň dovresti 
specificare meglio se č questo il tuo problema e che ti serve, cosě 
posso esser piů chiaro
bye
DKano

 posso esser più chiaro
il livello d'isolamento nn lo conosco...
provo  iquadrare meglio ciò che mi confonde che ho trovato leggendo
del materiale che ho su jdbc:
"Oggetti Connection sono synchronized ⇒ finchè thread che detiene
connection non la chiude, altri thread non riescono ad aprire
connessione
• In una Connection, per default, ogni Statement fa autocommit ⇒
per definire transazioni formate da più statement applicazione deve
– Mettere flag di autocommit a “false”
– Eseguire statement che fanno parte di transazione
– Eseguire “commit” finale"
"
Il mio quesito è se per transazioni sql formate da + statement :
-con l'autocommit a false si controlla solo l'esecuzione delle singole
statement eventualmente annulandole al fine di non lasciare il db con
dati erronei semplicemente all'interno della stessa connessione
(contesa da + thread di una servlet)
-se l'accesso al db provenisse da servlet diverse all'interno delo
stesso contesto, o da client diversi (client -->db) gli accessi remoti
in mutua esclusione come si gestirebbero? (cioè evitare la lettura di
dati inconsistenti ec..)

 dati inconsistenti ec..)
Con i livelli di isolamento. Quando apri una connessione puoi
specificare il livello di isolamento. Sostanzialmente i livelli
corrispondono al tipo di lock fatti sulle righe o tabelle del db; si va
da 'dirty read' che permette di leggere i dati "impipandosene" degli
eventuali lock (quindi anche i dati non commit-ati) a 'committed read'
che legge solo i dati che hanno avuto un commit e via così. Trovi tutto
nelle API di getTransactionIsolation, metodo di Connection. Ci sono
elencati i vari livelli e cosa permettono di isolare
bye
DKano

 elencati i vari livelli e cosa permettono di isolare
da servlet a db nn dovrei averne bisogno però nel caso servlet diverse
db o + client direttamente a un db approfondirò i livelli di
isolamento...

 permanente sul db
si, scrive i risultati che gli altri non vedono perché sono in quello 
che potremmo definire una specie di limbo; a meno che non si usi 'dirty 
read' come livello di isolamento, in quel caso vedrei anche i tuoi 
risultati temporanei.
bye
DKano

 risultati temporanei.
ok grazie approfondirò sto livello di isolamento :)