il lock su mysql serve a restituire dati certi o inserirli senza far doppioni?

[fullmetalmusic]

salve a tutti questo è il mio interrogativo: ho una pagina utente in cui si può accedere al database e inserire / aggiornare record in modo non esclusivo(potrebbe farlo qualsiasi utente) e allora avendo intuito il problema ho usato la tecnica del lock table che ho trovato qui http://www.html.it/pag/32159/transazioni-e-lock/ :nessun problema tecnico,ma volevo capire senza ombra di dubbio qual'è la portata del lock sulle tabelle:

se io blocco una tabella ,

#1)quando eseguo una query uso il read local per permettere agli altri di inserire ma anche
AGGIORNARE dati che non vadano in conflitto con la tabella che sto leggendo mentre se uso write blocco tutto finche i dati non sono aggiornati.che succede a coloro che intanto ci provano?
si ritrovano messaggi di errore?

#2)dato il contesto descritto all'inizio(pagina utente,etc etc),se invece di una query devo inserire ma anche aggiornare dati ,il lock sulla tabella è indicato oppure è meglio la transazione?

[in the web]

Parto dal presupposto che come storage engine usi InnoDB.

La transazione non è una cosa opzionale che puoi usare oppure no... è una cosa che usi, solo che puoi saperlo oppure no Usa esplicitamente i comandi START TRANSACTION e COMMIT.
Per fare in modo che le letture/modifiche fatte da varie connessioni non si scontrino tra loro, basta controllare che l'isolation level sia REPEATABLE READ. Va bene anche SERIALIZABLE, ma penso che tu non ne abbia bisogno. READ COMMITTED non garantisce l'integrità che tu vorresti e READ UNCOMMITTED non dovrebbe mai essere usato perché ha dei bug e non migliora molto le prestazioni.

Lascia perdere il LOCK TABLES: se usato con le transazioni fa più male che bene, perché sono due funzionalità che non sono progettate per essere usate insieme. Dubito fortemente che gli stessi sviluppatori abbiano testato a fondo il modo in cui interagiscono tra loro.

[fullmetalmusic]

ciao e grazie della risposta,davvero,perchè sn in crisi:

uso ovviamente innoDB non myisam(anche se la distinzione non so proprio dove sia)

mi sto affacciando ora alle problematiche di aggiornamento/inserimento dati multipli e come potrai ben capire ne so poco.

ho letto qui e la che la transazione è cmq in funzione anche se non imbrigliata dall'utente,in auto commit mode,e per dar un significato immediato,l'ho associata al problema dei pagamenti on line dove se cade la connessione, l'operazione rimane sospesa fino al suo completamento,e nel caso,decadere con lo scadere della sessione.

sono certo che si può ricicciare anche per ciò che interessa a me,ma il dubbio ora è un altro:

data la mole di record che potenzialmente possono essere interessati da operazioni -CONTEMPORNEAMENTE- aprire e chiudere transazioni a rotta di collo non potrebbe rallentare il database facendolo peraltro aumentare di volume con (passami il termine) una mole di dati temporanei aperti e chiusi ?

[in the web]

Originariamente inviato da fullmetalmusic
uso ovviamente innoDB non myisam(anche se la distinzione non so proprio dove sia)

Dentro il cofano sono completamente diversi, ma quello che interessa a te sono le transazioni. InnoDB le supporta, MyISAM no. Il LOCK TABLES è fatto per MyISAM, perché questo engine è progettato per il dataware house, dove la concorrenza non è un fattore importante. Su un sito, bloccare gli accessi all'intera tabella non è il massimo, anche se ovviamente nel caso di un sito piccolo si può fare.

Originariamente inviato da fullmetalmusic
ho letto qui e la che la transazione è cmq in funzione anche se non imbrigliata dall'utente,in auto commit mode,e per dar un significato immediato,l'ho associata al problema dei pagamenti on line dove se cade la connessione, l'operazione rimane sospesa fino al suo completamento,e nel caso,decadere con lo scadere della sessione.

Esatto. Praticamente le modifiche vengono scritte ma non sono effettive fino al commit.

Se usi autocommit, il commit è implicito, e viene fatto dopo ogni istruzione. In pratica questo garantisce "solo" una singola istruzione. Esempio, se fai una UPDATE, o vengono modificate tutte le righe, oppure nessuna.

Per garantire un'integrità un po' più complessa, come nel tuo caso, bisogna che una transazione racchiuda più istruzioni. Perciò fai START TRANSACTION, e alla fine fai COMMIT.

Originariamente inviato da fullmetalmusic
data la mole di record che potenzialmente possono essere interessati da operazioni -CONTEMPORNEAMENTE- aprire e chiudere transazioni a rotta di collo non potrebbe rallentare il database facendolo peraltro aumentare di volume con (passami il termine) una mole di dati temporanei aperti e chiusi ?

No, assolutamente. A parte il fatto che non puoi evitare le transazioni con InnoDB, puoi stare tranquillo perché vengono fatte in contemporanea, a meno che non agiscano proprio sulle stesse righe. Si dice che InnoDB ha il locking a livello di riga.
Con MyISAM invece useresti LOCK TABLES, e così facendo bloccheresti l'intera tabella (table level locking).
Ma su un sito medio-piccolo, queste cose non fanno nessuna differenza a livello di prestazioni. Casomai, se una pagina è lenta c'è un problema di indici.

Per ora preoccupati solo dell'integrità, usa REPEATABLE READ.

[fullmetalmusic]

grazie due volte per la chiarezza!