Newsgroup: it.comp.software.database
Titolo: [ORACLE] lock table

Ho bisogno di lockare una o piu' tabelle in lettura e/o scrittura. Mi
spiego: con lock "in lettura" intendo un lock con il quale sono
permessi tutti e soli gli accessi in lettura, e nessun accesso in
scrittura. Con lock "in scrittura" invece l'accesso e' permessa al solo
utente che ha lockato la tabella, gli altri non possono trovano il
semaforo rosso per qualsiasi operazione.
Ho visto la sintassi dei LOCK TABLE sul manuale Oracle, ma non mi
sembra che si possa riuscire semplicemente ad implementare tutto cio'.
Riporto dal manuale:
"A lock never prevents other users from querying the table. A query
never places a lock on a table. Readers never block writers and writers
never block readers"
Poi si legge che in modalita' exclusive
"EXCLUSIVE permits queries on the locked table but prohibits any other
activity on it"
Potrebbe essere la modalita' "lettura" che sto cercando, ma non si
capisce bene cosa intende: a chi si proibisce "any other activity"? E
in ogni caso, come lo risolvo il problema del lock "in scrittura"?
Grazie per l'attenzione, ciao!
GePs

 in ogni caso, come lo risolvo il problema del lock "in scrittura"?
Ciao GePs,
in generale i lock si ottengono attravero il package dbms_lock.
La tipologia e' quella che hai gia' letto dal manuale.
Di per se puoi imporre un lock su una tabella o un record che impedisca 
ad altri di acquisirlo a loro volta e quindi impedire operazione di 
modifica ai dati (fino al rilascio del lock).
Non puoi invece prevenire (giustamente) la lettura di una tabella.
Oracle costruito il suo meccanismo di isolamento per non essere 
bloccante in lettura (attraverso gli UNDO e "vecchi" rollback) 
aumentando le prestazioni e diminuendo la possibilita' di deadlock.
Leggendo il tuo post ho paura che tu stia tentando di implementare un 
tuo meccanismo di concorrenza basandoti su quello che l'RDBMS mette a 
disposizione (i lock).
In realta' ogni database transazionale nasce gia' come "servizio 
concorrente".
Non reinventare la ruota (rischieresti in piu' di non farla tonda).
Usa cio' che gia' c'e'. Per oracle gli isolation levels.
Ti conviene spiegare cosa vuoi implementare attraverso i lock.
Qualcuno potrebbe suggerirti una soluzione piu' elegante al problema.
Buona serata.
-- 
Fabrizio Magni
fabrizi...@mycontinent.com
replace mycontinent with europe

 Qualcuno potrebbe suggerirti una soluzione piu' elegante al problema.
Grazie mille, sei stato veramente gentile. Ti faro' sapere.
Ciao!

Sono spiacente di annunciarti che:
 > Forse non mi sono spiegato bene: ho bisogno di due tipologie di lock:
 > 1) lock che una volta acquisito blocchi gli accessi in lettura agli
 > altri thread/processi/utenti
Non esite.
 > 2) lock che permette a tutti, anche chi lo ha acquisito, solo ed
 > esclusivamente accessi in lettura.
 >
Non esiste.
Al massimo, per il 2, puoi impedire l'acquisizione del lock ad altri (e 
quindi eventuali modifiche dei dati) ma non alla transazione stessa che 
ha acquisito il lock.
Temo tu debba realmente ripensare l'applicazione (oltretutto non credo 
nemmeno che un approccio simile possa considerarsi corretto anche per 
mysql).
Ciao


 mysql).
Ah non lo so. O quello che ha scritto il codice che sto modificando ha
le idee meno chiare delle mie, o sono io a non aver capito bene. Faro'
il possibile!
Ciao!

 esclusivamente accessi in lettura.
Non è un lock... basta mettere la session in read only.
Credo che si possa fare... è dura ma ok.
g

 
Al massimo parliamo di transazione in sola lettura. Ma in quel caso non 
si sara' in grado di modificare nessun altra tabella.
Una limitazione non da poco!
Senza contare che si forza la consistenza (in lettura) a livello di 
transazione, equivalente ad un cambio di livello di isolamento (SET 
TRANSACTION ISOLATION LEVEL SERIALIZABLE).
Se l'applicazione e' concorrente e si deve basare sulle modifiche 
effettuate da altre sessioni allora la soluzione non e' minimamente 
pensabile.
Aperto alla discussione.


 Aperto alla discussione.
Per un niubbo come me e' abbastanza gratificante dare l'avvio ad una
discussione interessante :)

 Una limitazione non da poco!
pardon intendevo transazione...
no... si imposta la transazione read only e quando non serve si risolve
la transazione...
ripeto... sto offrendo delle potenziali soluzioni non conoscendo i
reali
problemi.
g

 
Rimane il problema che sessione 2 puo' comunque eseguire delle insert, 
magari rendendo vano cio' che si e' appena fatto.
Non vorrei che sembrasse che mi accanisco sull'argomento ma purtroppo 
vedo spesso dei mostri applicativi che poi divengono un inferno da 
amministrare.
In particolare al momento mi sto facendo grasse risate su un database 
che produce deadlock a ripetizione e che al momento ha 323 
(trecentoventitre) lock su 98 sessioni presenti (64 sessioni sono 
bloccate l'un l'altra dai relativi lock).
Gli eventi di wait che leggo dallo statspack sono una barzelletta!
E questi vogliono andare in produzione tra breve!!!!!


 E questi vogliono andare in produzione tra breve!!!!!
Beh... dichiarala non esercibile :)
g (Giorgio)