riflessione/dubbio - atomicità mysql/sistemi multiprocessore

[markzzz]

salve. mi farebbe piacere fare chiarimento su questa cosa che mi lascia un pochino perplessa.
ora mi direte : vai e leggiti le guide prima di sparare a vanvera. bhè, ho letto un bel pò di materiale a riguardo, ma non ho trovato nulla che chiarisse la mia perplessità.

allora, prima di porre la questione, vediamo se ho capito l'atomicità :

ammettiamo che io invi una richiesta a una pagina php che fà un'operazione di select, o insert, o update, o delete all'interno di una tabella; mysql imposta il lock su TUTTA LA TABELLA (quindi tutti i records della tabella) finchè l'operazione in corso non è finita (per un read- insert/delete/update per esempio, non per un read-read).

es. user1 fà un select * in una tabella di 2000 records. se mentre l'operazione è in corso arriva l'user2 che vuole fare una delete o un update o un insert sulla stessa tabella, verrà bloccato finchè tutti i 2000 records non sono stati letti. se invece user2 vuol fare una semplice read accederà senza problemi. esatto?

ora, la questione è questa : mysql può effettuare due query contemporaneamente giusto? (cioè, nello stesso instante può iniziare due query?);

perchè secondo il protocollo tcp questo sarebbe da escludere (i dati vengono gestiti "sequenzialmente", non possono arrivare due connessioni "nello stesso preciso istante"), però oggigiorno con i sistemi multiprocessore questo potrebbe avvenire...

es. supponiamo che il pc prenda all'istante 1 e 2 le due connessioni tcp, e vengano gestite direttamente dalla cpu1 e cpu2. per vari motivi/sfortuna (ma che può accadere) le due cpu inviano contemporaneamente la richiesta di query al database (allo stesso istante, sulla stessa tabella). è quì che mi sorgono i dubbi. con una configurazione del genere avrei dei grossi problemi.

ammeno che non ci siano dei meccanismi mysql che prevedono anche questo scenario
spero di essere stato chiaro! grazie per chi vorrà fare luce su questa storia.

cordiali saluti

[Electro]

Originariamente inviato da markzzz
salve. mi farebbe piacere fare chiarimento su questa cosa che mi lascia un pochino perplessa.
ora mi direte : vai e leggiti le guide prima di sparare a vanvera. bhè, ho letto un bel pò di materiale a riguardo, ma non ho trovato nulla che chiarisse la mia perplessità.

allora, prima di porre la questione, vediamo se ho capito l'atomicità :

ammettiamo che io invi una richiesta a una pagina php che fà un'operazione di select, o insert, o update, o delete all'interno di una tabella; mysql imposta il lock su TUTTA LA TABELLA (quindi tutti i records della tabella) finchè l'operazione in corso non è finita (per un read- insert/delete/update per esempio, non per un read-read).

es. user1 fà un select * in una tabella di 2000 records. se mentre l'operazione è in corso arriva l'user2 che vuole fare una delete o un update o un insert sulla stessa tabella, verrà bloccato finchè tutti i 2000 records non sono stati letti. se invece user2 vuol fare una semplice read accederà senza problemi. esatto?

ora, la questione è questa : mysql può effettuare due query contemporaneamente giusto? (cioè, nello stesso instante può iniziare due query?);

perchè secondo il protocollo tcp questo sarebbe da escludere (i dati vengono gestiti "sequenzialmente", non possono arrivare due connessioni "nello stesso preciso istante"), però oggigiorno con i sistemi multiprocessore questo potrebbe avvenire...

es. supponiamo che il pc prenda all'istante 1 e 2 le due connessioni tcp, e vengano gestite direttamente dalla cpu1 e cpu2. per vari motivi/sfortuna (ma che può accadere) le due cpu inviano contemporaneamente la richiesta di query al database (allo stesso istante, sulla stessa tabella). è quì che mi sorgono i dubbi. con una configurazione del genere avrei dei grossi problemi.

ammeno che non ci siano dei meccanismi mysql che prevedono anche questo scenario
spero di essere stato chiaro! grazie per chi vorrà fare luce su questa storia.

cordiali saluti

Non credo sia possibile che arrivino allo stesso instante, per quanti possano arrivare contemporaneamente, ci sarà sempre qualche nano secondo (volendo qualche unità più piccola) di differenza, che farà arrivare una prima e l'altra dopo.

[markzzz]

partendo dal principio :

come ho capito l'atomicità delle tabelle è giusta? nel senso la tabella (e tutti i suoi records) viene bloccata fino alla fine della read? (e quindi se uno ci stà scrivendo non posso leggerere tutti i records e viceversa) ?

detto questo, credo anche io che sia difficilissimo mandare due richieste contemporanemante, ma non impossibile (e credo che nell'informatica questo venga considerato), no?

[*pragma]

l'atomicità delle tabelle è giusta.
Banalizzo con un esempio:
un signore acquista all'ikea articoli per arredo, è disponibile solo 1 determinato armadio, 100 sedie delle quali ne sceglie 4 e svariati altri articoli.
Comincia l'operazione alla cassa, vengono atomizzate le tabelle (magazzino, uscite ecc...) che riguardano l'armadio fino a che l'operazione non va a buon fine (potrebbero esserci problemi con carte di credito) e che mettono in attesa (solo su quell'articolo) le altre casse.
Non può accadere che ad un'altra cassa un altro signore cominci ad acquistare 30 secondi dopo lo stesso armadio (e solo quello) e pagando in contanti termina prima l'operazione.
La morale sarebbe che il primo signore acquista varie cose, paga tutto, ma l'armadio l'ha perso.

Questi dovrebbero essere problemi di amministratori di DB.
Un backup coerente esegue LOCK TABLES, sulle tabelle interessate, eseguito da FLUSH TABLES per le tabelle.
Questa istruzione è necessaria per garantire che tutte le pagine degli indici attivi siano scritte sul disco prima di avviare il backup.
Si può utilizzare SELECT INTO ... OUTFILE . Il file di uscita (da backup) non può esistere già perchè il rischio di sovrascrivere i file esistenti, corrompendo la referenzialità delle tabelle di join, sarebbe concreto.
Una tecnica per eseguire il backup è l'uso del programma mysqldump, oppure mysqlhotcopy.
Le modalità dipendono pure dal type di tabelle.

Mi sono ricordato dell'acronimo ACID ed ecco cosa spunta di wikipedia
http://it.wikipedia.org/wiki/ACID
Comunque non sono un amministratore di DB.
ciao

[LeaderGL]

Originariamente inviato da markzzz
es. supponiamo che il pc prenda all'istante 1 e 2 le due connessioni tcp, e vengano gestite direttamente dalla cpu1 e cpu2. per vari motivi/sfortuna (ma che può accadere) le due cpu inviano contemporaneamente la richiesta di query al database (allo stesso istante, sulla stessa tabella). è quì che mi sorgono i dubbi. con una configurazione del genere avrei dei grossi problemi.

ammeno che non ci siano dei meccanismi mysql che prevedono anche questo scenario
spero di essere stato chiaro! grazie per chi vorrà fare luce su questa storia.

cordiali saluti

come ho capito l'atomicità delle tabelle è giusta? nel senso la tabella (e tutti i suoi records) viene bloccata fino alla fine della read? (e quindi se uno ci stà scrivendo non posso leggerere tutti i records e viceversa) ?

detto questo, credo anche io che sia difficilissimo mandare due richieste contemporanemante, ma non impossibile (e credo che nell'informatica questo venga considerato), no?

ti posso consigliare di farti una domanda che forse ti aprirà alcune strade per risolvere il problema:
1) cosa significa, in termini pratici, fare un LOCK su una tabella?
2) cosa viene bloccato e come si capisce che una cosa è bloccata?

[markzzz]

Originariamente inviato da *pragma
che riguardano l'armadio fino a che l'operazione non va a buon fine

il tuo esempio mi ha fatto un pò di confusione

quando dici "che riguardano l'armadio" intendi solo l'armadio? quindi sulle sedie qualcuno potrebbe intervenire? perchè il mio dubbio sostanziale dei lock è questo :

il DB fà il lock sul singolo record o su TUTTA la tabella?

cioè, è possibile che mentre faccio un select su 2000 record di una tabella, uno possa scriverci?

es. 2000 record, arrivo a fare il SELECT del 1000° : se in quel preciso istante uno fà un delete o insert o update sul 864° o sul 1300° può?

a rigor di logica, spero propio di no

Originariamente inviato da LeaderGL
ti posso consigliare di farti una domanda che forse ti aprirà alcune strade per risolvere il problema:
1) cosa significa, in termini pratici, fare un LOCK su una tabella?
2) cosa viene bloccato e come si capisce che una cosa è bloccata?

1) significa bloccare tutti i record della tabella, prima di liberarli (solo su operazioni di read-editing, read-read i locks non vengono presi in considerazione).

2) effettivamente è quello che vorrei sapere

[LeaderGL]

Originariamente inviato da markzzz
1) significa bloccare tutti i record della tabella, prima di liberarli (solo su operazioni di read-editing, read-read i locks non vengono presi in considerazione).

2) effettivamente è quello che vorrei sapere

si ma cos'è una tabella, dove risiede?!

il termine "tabella" è una cosa molto astratta, non si dice al computer "blocca una tabella"...il computer conosce altro.

ti faccio un esempio ma non farti distrarre: se due persone vogliono accedere in scrittura allo stesso files non è possibile, perchè? non certo perchè il processore è uno e lo usa un utente alla volta (altrimenti per i files remoti sarebbe la fine, lo scheduling non servirebbe a niente, etc) ma perchè la struttura nel filesystem che identifica il file possiede un campo che indica se il file è bloccato o no; quando il primo utente tenta di scrivere/modificare un file lo blocca e quindi tutti gli altri verificando se è bloccato o no possono procedere o meno alla scrittura.

ci stiamo avvicinando?

[markzzz]

bhè si, ho fatto all'università un corso, sistemi operativi 1 : ti stai riferendo ai file descriptor giusto? (nei sistemi unix per esempio).

questo però non toglie il fatto che sui database (mysql, per quel che interessa a me) non ho idea se il lock avviene sempre sulle tabelle o sui singoli record

[LeaderGL]

può avvenire su entrambi (sia tabella che record, anche se con modalità un po diverse).

il concetto è che anche se il sistema fosse multiprocessore e multicore il lock di un dispositivo, un file, una tabella di un database è una cosa che non riguarda il processore...quindi non farebbe alcuna differenza.

il primo che impone il lock sulla risorsa la usa, gli altri aspettano.

[markzzz]

ok, quindi per quanto riguarda la prima perplessità :

come faccio a sapere se il database che uso lavora con lock tabella/lock records?

per il secondo punto :
tu dici : "il primo che impone il lock lo usa", ma se la richiesta avvenisse (appunto) nel medesimo istante? cioè se la cpu1 e la cpu2 inviano al nanosecondo la richiesta di lock? viene gestita? sicuramente ci saranno dei meccanismi complessi (non credo si utilizzino semafori, bensì monitor o condition variables), però la richiesta parte comunque dalla cpu...

inoltre (visto che ci siamo) vorrei fare un'osservazione : ragionando un secondo, se mantengo i lock sui singoli records posso avere una condizione di deadlock; nel caso delle tabelle invece questo problema viene eliminato...