www.vincenzomanzoni.com

[Andrea]

Prendiamo una transazione tipo

[Francesco]

io ti spiego come l'ho capita io, poi potrei essere nel torto quindi non fidarti

allora, prima di tutto la storia del buffer è una cosa a parte, è meglio non mischiarla con la concorrenza delle transazioni anche perchè presenta problemi diversi sui quali devo ancora riflettere... Per quello che dicevi riguardo al commit, quando viene eseguito è impossibile il rollback, ma i valori sono già scritti, man mano che le istruzioni di write vengono effettivamente eseguite. Di questo sono quasi sicuro perchè altrimenti non ci sarebbero problemi di concorrenza in quanto si avrebbe un'atomicità di basso livello di ogni singola transazione, (appunto nel momento del commit) cosa purtroppo impossibile.
_________________
God is real........... unless declared integer or long

[Francesco]

riassumendo...

[abaddon]

uhmm non vorrei dire na cazzata ma da quel che ho visto allo stage sbirciando nel lavoro di Marini (doveva creare un tool di replicazione di db e mantenerli sincronizzati poi) mi pare che usando il commit una query viene realmente scritta su db solo quando tutte le query contenute nella commit vanno a buon fine, altrimenti non si vede nulla. Non ne sono certo, dovrei chiedere a marini che ormai s'è fatto una cultura su ste cose... magari domani gli chiedo se mi ricordo^^

anche perchè se non ricordo male aveva avuto all'inizio un problema di scrittura su db, in pratica gli rimanevano aperti i commit o qualche cosa del genere e il db non scriveva nulla, potrei comunque aver capito male, mi informo e do conferme o smentite^^

[Francesco]

forse sono cose un po' diverse, cmq un problema può essere:

- ho una transazione in corso che esegue una scrittura
- inizia un'altra transazione che va a leggere il dato che ho scritto
- la prima transazione viene uccisa da un rollback
-> la seconda transazione sta operando su un dato potenzialmente scorretto

quello di eseguire una query tutta al momento del commit non è una soluzione perchè si potrebbero avere 2 inconvenienti:

1- la query potrbbe operare su un buffer, quindi c'è il rischio che venga eseguita usando dati obsoleti e che produca di conseguenza un risultato inconsistente.
2- la query "fa tutto" quando riceve il commit, ma essendo il "tutto" non eseguibile in modo atomico è comunque soggetta ai problemi tipici della concorrenza. Infatti una transazione, o query, può contenere diverse istruzioni di lettura-scrittura.
_________________
God is real........... unless declared integer or long

[abaddon]

mi sono informato^^

il commit funziona così:

si manda la query al db, il db la verifica, la esegue "virtualmente" se tutto va bene la committa e la scrive effettivamente sul db.

se ci sono piu' query in una commit tutte le query vengono eseguite, controllate e messe in una memoria del db in attesa che la commit si concluda e che dia esito positivo, appena la commit da esito positivo i dati nel db vengono aggiornati.

se una persona fa un select su una tabella non vede i dati che devono essere ancora committati.

è questo che chiedevate? o_O altrimenti non ho capito il vostro dubbio...

[Francesco]

probabilmete parliamo di cose diverse, noi stavamo parlando di transazioni e non di query, non so se poi cambi qualcosa riguardo alla gestione, probabilmente dipende anche da come gestisce queste cose il DBMS, cmq Paraboschi non ce l'ha spiegata così, oppure quello che dici tu è il risultato di alto livello dovuto a una gestione corretta della concorrenza a livello più basso, cioè quello che stiamo facendo adesso a Sis info 2.

In effetti prova a pensarci: se come dici tu quando viene eseguito il commit i dati vengono salvati fisicamente sul DB; se mentre vengono salvati e ancora non si è finito arriva una select questa su cosa opera? su dati incompleti
_________________
God is real........... unless declared integer or long

[abaddon]

le transazioni sono un insieme di operazioni che il db fa atomicamente che se vanno a buon fine committa e scrive sul db.

se una query arriva e fa una select su uno o piu' campi di una tabella che ha in atto una transazione non conclusa i dati della transazione non si vedono.

[Francesco]

le transazioni sono gestite in modo da essere eseguite in modo atomicho, ma di per se non lo sono, è proprio la fase di scrittura sul db che è critica. Quello che dici tu è giusto, ma parliamo di un livello più alto di quello che stiamo studiando e che intendeva Andrea.
_________________
God is real........... unless declared integer or long

[abaddon]

cosa significa "di per se non lo sono"?

presumo che essendo atomica una transazione, nel momento in cui il commit ha esito positivo e inizia a scrivere realmente su db in quel momento si manifesta l'atomicità della transazione.

[Francesco]

intendo dire che essendo la transazione costituita da più istruzioni, lo scheduler del SO non può assegnare tutto il tempo necessario per svolgerla in una volta sola, quindi è necessario cautelarsi verso le altre operazioni che potrebbero venire eseguite quando lo scheduler alloca il tempo CPU ad un altro processo, mentre le istruzioni della transazione non sono state ancora eseguite completamente.
Prova a pensarci, se fosse veramente atomica, nel senso ci metto 1 quanto di tempo ad eseguirla, non sarebbero neanche necessari i commit e i rollback, visto che i due possibili esiti di un'operazione puramente atomica sono o eseguita completamente o non eseguita del tutto
_________________
God is real........... unless declared integer or long