Newsgroup: it.comp.software.database
Titolo: Help sulle Transazioni

Praticamente mi succede questa cosa:
ho un rekord che puo' essere cancellato da utenti in maniera 
contemporanea.
allora devo individuare se qualcuno lo ha cancellato ma 
quando faccio la select su quel record mentre la transazione 
di un altro utente non ha ancora committato quella dannata 
query di select mi restituisce il valore vecchio e il rekord 
non risulta cancellato al che partono delle procedure che 
non devono partire... cioe' partono 2 o piu' volte in quanto 
le faccio e poi anche l'altro(2 al max mi sembra che possono 
avere accesso a quel record.)
uso postgres (ho provato anche con il livello di isolamento 
della transazione SERIALIZABLE.)
e non capisco perche' la select non aspetta la fine della 
transazione e poi mi dice che il record non c'e'!!!
Vorrei che leggesse i dati committati e non ancora non 
committati.
unica cosa che potrei fare e' far partire il delete anche 
all'altro e poi se il numero di righe affected e' ==0 allora 
vuol dire che ha gia' cancellato l'altro...
e' affidabile sta cosa?
grazie per eventuali consigli.

 valore vecchio e il rekord non risulta cancellato al che partono delle
Questo comportamento è normalissimo: se la transazione non è "committata" un altro utente non vede le modifiche,
altrimenti quale sarebbe il vantaggio di avere le transazioni?
Il tuo problema, se non l'ho capito male, si può risolvere facendo una "SELECT FOR UPDATE"
in modo che i record selezionati vengano bloccati, quindi se qualcun'altro li ha già bloccati prima l'utente resta in
attesa finché l'altro non ha deciso cosa fare delle sue modifiche (commit o rollback).
La spiegazione è un po' approssimativa ma spero di essere stato chiaro.
Ciao.

 La spiegazione è un po' approssimativa ma spero di essere stato chiaro.
Ho capito e sembra funzionare, grazie!
pero' c'e' un problema di fondo :-(
non riesco a testarlo come posso fare??

 poi mi dice che il record non c'e'!!!
Purtroppo sei stato vittima del mvcc (di per sé cosa buona); con
l'mvcc si è avuto un notevole aumento di flessibilità e di
prestazioni, in cambio di una piccola perdita di integrità.
Da questo punto di vista, forse sarebbe meglio dare la possibilità
di specificare il mvcc di volta in volta, e lasciarlo disattivato
per default.

Ar4g0rn Work ha scritto:

Forse perché le procedure sono troppo rapide e non riesci a fare in modo di eseguirle contemporaneamente?
Se il problema è questo potresti provare ad inserire nell'applicazione un "sleep" tra la SELECT FOR UPDATE e la DELETE
(solo per il test ovviamente :)).

 prestazioni, in cambio di una piccola perdita di integrità.
Questo argomento mi interessa... cosa intendi per "piccola perdita di integrità"? Potresti, se hai tempo e/o voglia,
approfondire oppure dare qualche riferimento?
Grazie.

 (solo per il test ovviamente :)).
okey va!! Grazie a tutti!!!! :-D

"Zac":


Vedi questo paper della Ibm, ultimo baluardo per l'adesione completa
allo standard Ansi e contro la mvcc (almeno fino ad un po' di tempo
fa, poi non so se anche loro hanno ceduto), specialmente l'esempio
dell'acquisto doppio di biglietto aereo:
ftp://ftp.software.ibm.com/software/data/pubs/papers/readconsistency.pdf
Gli argomenti si concentrano un po' troppo secondo me su aspetti
tecnici tipo velocità, occupazione di memoria etc, il che
non è il punto centrale imho.
Poi, un passo nei docs di PG, da cui quoto:
http://www.postgresql.org/docs/8.1/interactive/applevel-consistency.html
"Another way to think about it is that each transaction sees a
snapshot of the database contents, and concurrently executing
transactions may very well see different snapshots. So the whole
concept of "now" is somewhat ill-defined anyway. This is not normally
a big problem if the client applications are isolated from each other,
but if the clients can communicate via channels outside the database
then serious confusion may ensue."
Da notare che l'ultima frase può ricondursi ad un problema similare
al post originale.
Il tutto può risolversi semplicemente aggiungendo una clausola nelle
query, ma ciò che mi lascia perplesso è che introducendo il mvcc
*attivo di default*, cambio il comportamento di programmi
preesistenti, col rischio di comportamenti erronei e/o imprevisti.
Il mio pensiero generale è che la data integrity deve essere a carico
del dbms e al massimo del dba, non del programmatore.
Molto credo che nasca dal fatto di considerare il lock come un
male da evitare a tutti i costi; io ho sempre visto il lock come
un utile semaforo, di cui l'attesa è il prezzo da pagare.
bye

 
Secondo la documentazione di PostgreSQL la seconda transazione fallisce.
Molto più subdolo l'esempio riportato in
http://www.postgresql.org/docs/8.1/static/transaction-iso.html#XACT-SERIALIZABLE
Saluti  Manlio Perillo

 Secondo la documentazione di PostgreSQL la seconda transazione fallisce.
Humm interessante, in questo modo perlomeno si eviterebbe un commit
potenzialmente erroneo...

The man with two watches ha scritto:

E ci mancherebbe direi.
Mi sembra strano che Oracle effettui il commit silenziosamente, magari
nelle versioni più recenti non accade più.
Oppure magari la documentazione di PostgreSQL non è corretta (ma mi
sembrerebbe *molto* strano).
Comunque per fortuna che a queste cose non ci devo pensare... ;-).
Saluti  Manlio Perillo

 non è il punto centrale imho.
Questo argomento è molto interessante.
Penso che il documento della IBM sia molto semplicistico e che faccia un
po' di confusione tra MVCC e livelli di isolamento, ma sto studiando la
questione e non ho ancora finito.
Nel frattempo, potresti leggere il seguente articolo molto completo sul
funzionamento di Oracle e darmi un parere?
http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html
Bye :-)
-- 
Rudy
http://rdbland.blogspot.com/
e-mail a 
email.it

 Secondo la documentazione di PostgreSQL la seconda transazione fallisce.
Potresti indicare dove viene affermato ciò nella documentazione?
Bye
-- 
Rudy
http://hillrudy.blogspot.com/
e-mail a 
email.it

 
http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html#XACT-SERIALIZABLE
Saluti  Manlio Perillo

"Rudy"


Effettivamente l'articolo è molto efficace, ed ho molto apprezzato
l'onestà con cui vengono esposti anche i difetti della soluzione
(mi pare che non abbia risparmiato niente) per cui tanto di cappello
visto che viene dal produttore stesso.
Il mio entusiasmo diminuisce quando si inizia a parlare di
interazione utente -> programma -> db, dato che il programmatore
deve farsi carico di pensare controlli extra, mentre il mio pensiero
è che il dbms debba restituire dati sempre corretti PER DEFAULT, a
meno che io non specifichi un livello più basso (e volerne gestire
le conseguenze).
Comunque, essendo una tecnologia, sicuramente andrà evolvendosi,
pertanto c'è da scommettere che migliorerà ancora.
bye

 ho un rekord
Cos'e` un "rekord" ?
Enrico

 
http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html#XACT-SERIALIZABLE
Ho capito, è il caso del serializable.
Beh alla fine la differenza sembra che stia nel fatto che con Oracle e
PostgreSQL bisogna salire a livello applicazione per garantire la
concorrenza con "SELECT FOR UPDATE", mentre per DB2 ci deve essere
qualche altra soluzione, che dovrebbe comportare però pesanti blocchi in
lettura e scrittura. La cercherò nella documentazione, io non conosco
per nulla DB2.
Bye
