[Transazioni] Inserimento istruzioni in unica transazione.

[wartpro]

Buongiorno a tutti,

sto leggendo questa guida e in particolare sono arrivato a questa lezione ( http://database.html.it/guide/lezion...i-un-database/ ) ma non ho compreso bene un passaggio e vorrei ricevere un chiarimento se possibile.

Al centro della pagina, nella sezione Transazioni dice:

Se le due istruzioni fossero state inserite in una transazione, il problema non sarebbe sorto, dato che la transazione del secondo utente non avrebbe potuto leggere il valore della giacenza fino a quando non fosse stata completata la transazione del primo utente.

Il periodo è preceduto da due esempi di codice che interrogano il database per sapere la giacenza in magazzino di un prodotto e successivamente inviano l'istruzione di aggiornamento dopo aver richiesto l'ordine (da parte di un utente).

Ma cosa vuol dire "se le due istruzioni fossero state inserite in una transazione.." ?

Significa che le istruzioni di interrogazione/aggiornamento sarebbero dovute essere inserite in un'unica (appunto) istruzione di codice?

Ad esempio così?

SELECT giacenza FROM prodotti WHERE prodottoID=1453

UPDATE prodotti
SET giacenza=giacenza-1
WHERE prodottoID=1453 

Cioè entrambe le istruzioni in un'unica funzione? ..dico bene?


Grazie a tutti.

----------
NB: non so se ho scritto un obrobrio unendo quelle due porzioni di codice ma..forgive me..ho iniziato ora lo studio dei linguaggi SQL

[deleted_29]

unica "transazione", attenzione poi ai livelli ACID.
Versione superbreve: puoi serializzare gli accessi in scrittura, questo però determina un deterioramento delle prestazioni a cagione dei lock multipli che vengono posti.

[wartpro]

Grazie per la risposta Franz ma...

...cos'è una transazione?

- Un blocco di codice che include le istruzioni da compiere (come quello che ho riportato) ?
- ..altro che non so?


Grazie mille.

[deleted_29]

l'argomento è davvero vasto, penso che troverai tutte le guide che vuoi anche su html.it.

versione superbreve: sì, hai intuito bene. Un transazione è l'esecuzione di un certo numero di comandi, che avviene in modo "atomico".
Ossia O tutta la transazione va a buon fine, oppure tutta fallisce (rollback) e si torna allo stato precedente, come se non fosse avvenuto nulla.

dal momento che la gestione della concorrenza (*altro vasto argomento, non mi sembra il caso di fare un saggio qui) è "complicata", si hanno dei tradeoff, dei compromessi, tra
il livello di parallelismo (=velocità) con quello di "affidabilità" dei risultati (serializzazione).

In sostanza nel modo più "rigido" se arrivano X comandi (transazioni) - sto banalizzando assai - semplicemente vengono eseguite una dopo l'altra, sequenzialmente (* in realtà c'è tutta una teoria riguardo alle letture etc.etc.)

Così sei sicuro di non avere problemi: i contatori, ad esempio, vengono incrementati sequenzialmente
---
All'estremo opposto hai che gli X comandi vengono eseguiti contemporaneamente, tra l'altro senza nessuna particolare garanzia sull'ordine.
In questo caso avrai le prestazioni massime (=parallelismo), ma "casini" nel caso in cui le transazioni operino sugli stessi dati (=son 'cazzi tuoi lato applicazione far sì che le transazioni non si "pestino i piedi").
---
Bon, tra questi due estremi vi sono altri livelli (tipicamente 2) intermedi.
Come si fa a decidere? Normalmente sono delle impostazioni, dici al motore SQL "guarda voglio un livello alto di garanzia di non avere problemi di concorrenza", oppure "me ne frego, non essere molto fiscale nei controlli, mi interessa velocità"
---
Qualcosina si capisce?

[wartpro]

Franz.....NICE SHOT !!!

Sei stato chiarissimo nel darmi questa "infarinatura" sull'argomento. Praticamente mi hai dato un più che ottimo punto (ma direi SPUNTO) di partenza per iniziare ad applicarmi.

E direi che essendo la prima volta con la quale mi relaziono con l'argomento "Base di dati" è un buon inizio..buonissimo!!


for (i=0;i<1.000.000;i++) { echo "Grazieeeeee!! :-)
"; }