Newsgroup: it.comp.software.database
Titolo: Deadlock e strategie di controllo

Ciao,
mi interesserebbe sapere quali database, oltre a PostgreSQL e Interbase,
offrono un controllo avanzato (controllo sugli eventuali cicli del
waits-for graph) per il rilevamente dei deadlock (forse la domanda
giusta č: esiste ancora qualche database che usa la politica del
timeout? ;).
Sono sicuro di Interbase e PostgreSQL perchč ne ho potuto visionare
direttamente il codice. Sul sito di Oracle (e su quello di Sybase) non
ho trovato nulla in proposito dei deadlock (ma me lo aspettavo)...
Ciao.

 database che usa la politica del timeout? ;).
Che io sappia no.
Per quanto riguarda Oracle, il meccanismo di funzionamento del
Rollback impedisce (piu' o meno) l'avvento di un deadlock, ci 
possono essere dei problemi se i rollback sono molto piccoli o 
sono molto pochi in presenza di grosse transazioni, in questo
caso potresti ricevere l'errore "snapshot too old", che significa
"non sono riuscito a ricostruire il valore del record dal rollback"
aka: "aumenta i rollback idiota!".
Per quanto riguarda SQL Server/Sybase/Access (credo che tutti e
tre implementino lo stesso sistema), ogni volta che fai una SELECT
il db acquisisce un READ-LOCK sui record, impedendo di fatto ogni
successiva modifica fino a che non hai chiuso il cursore. I dati
possono essere letti, ma non modificati.
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 direttamente il codice.
????
Apri una transazione di aggioramento su una tabella, e non terminarla.
Apri una seconda transazione di lettura sulla stessa tabella.
Non mi dire che la seconda transazione non termina mai, e non c'e' un
timeout. Mi rifiuto di credere che possa esistere codice cosi' mal fatto.
Di sicuro non ho capito cosa intendevi dire, fammi capire.
ciao
-------------------------------------------------------
Messaggio inviato da 
http://www.sandlab.org/newsgroup/
Accesso gratuito via web ai Newsgroup

Davide Quack wrote:

Semplice: per verificare la presenza dei deadlock, il modo più semplice che
conosco è quello utilizzare un timeout: dopo un pò di tempo che una
transazione è in attesa di una risorsa, il responso per l'acquisizione di
tale risorsa è dato negativo (magari la transazione viene abortita).
I database moderni però, utilizzano un controllo più sofisticato
(semplificando, si utilizza un grafo delle transazioni per la rilevazione di
cicli).
Io mi chiedevo se sono in commercio database che supportano un controllo di
deadlock basato su timeout.
Tutto qui.
Il timeout di solito viene utilizzato per stabilire quando è il caso di
controllare per la presenza di un deadlock.
Il secondo sistema è più "avanzato"  in quanto rileva esattamente i deadlock
e solo quelli (senza fa riferimento a quando li rilevano ovviamente), mentre
la tecnica con timeout rischia di considerare un'attesa fisiologica di una
transazione come un deadlock
Ciao.

 Il secondo sistema č piů "avanzato"  in quanto rileva esattamente i deadlock
"esattamente"?
Il caso che ti ho descritto non riuscirebbe a determinarlo nemmeno con la
sfera di cristallo.


 Accesso gratuito via web ai Newsgroup
E' vero, non avevo letto attentamente il post tuo. Rimane il fatto che il caso che
hai descritto non è un deadlock...
Ciao

 hai descritto non č un deadlock...
Insomma. Dal punto di vista tecnico ha ragionissima, ma non e' solo un
sofisma. Eccoti la versione deadlock:
Apri una connessione.
Chiamiamiamo questa connessione A
La connessione A accede alla risorsa X in transazione.
Non chiudiamo la transazione.
Pausa.
Apri un'altra connessione.
Chiamiamiamo questa connessione B
La connessione A accede alla risorsa Y in transazione.
Non chiudiamo la transazione.
Pausa.
Caffe'.
La connessione A vuole accedere alla risorsa y in transazione.
Andiamo a Pranzo.
Se magna e se beve.
Torniamo.
Il sistema o e' in timeout, o e' morto.


 Il sistema o e' in timeout, o e' morto.
o le connessioni, e i relativi utenti, sono di una lentezza esasperante,
oppure--
ma tu il caffe' lo prendi _prima_ di pranzare ? :>

javalab wrote:

Hu, sono le 11.46 ed io non ho ancora preso il mio..;)

 Il sistema o e' in timeout, o e' morto.
No, stà benissimo. Grazie. E tutti gli utenti stanno lavorando 
tranquillamente.
Il bello viene adesso, quando A e B cercano di fare la Commit.
Se il loro record è già stato modificato e committato da qualcun altro 
prima di loro, la versione che hanno del record risulta obsoleta e non 
c'è niente da fare: ROLLBACK.
Nel caso piacevole in cui nessun altro abbia modificato i record X ed Y 
(ammesso che abbiano modificato tutto il record, non ricordo se IB6 
faccia il versioning a livello di campo, ma non importa) il primo fra A 
e B che fa la commit vince (si fa per dire), all'altro non resta che il 
RollBack. Che è automatico se si disconnette.
E' una storia lunga, ma mi sembra che il caso in questione non sia un 
deadlock. L'ho raccontata bene?
:)
Dimenticavo. Se il record lo leggi e basta, non te ne fa una copia...
Ciao.
Mimmo.

 c'è niente da fare: ROLLBACK.
Bello schifo. 
Il rollback lo decide il programmatore, non certo il DB a capocchia.
Il DB al massimo di fa fallire la transazione, che cosa diversa assai da
fare un rollback.
Il DB non puo' sapere le ripercussioni di un rollack "implicito", motivo
per cui deve essere esplicito.
Ovviamente, a parte il tono che spero tu non abbia trovato offensivo
(nessuna intenzione di offendere, solo di discutere), io trovo che se un
DB funziona cosi', allora non e' un buon DB.
P.S.
Io il caffe' lo prendo alla mattina, dopo pranzo e la sera.
Il mio stomaco sta in ottima salute.


 Il mio stomaco sta in ottima salute.
P.S.
Anche io.
Ciao.
Mimmo.
---
Togli tre ZUM ed il punto per rispondere in privato.