Come gestire la concorrenza tra record?

[rizzotti91]

Salve mi sono avvicinato da poco alla programmazione in visual c# e sono tutt'altro che un programmatore esperto. Fatta questa piccola premessa, ho l'importante necessità, di implementare una gestione della concorrenza su un record durante le operazioni di modifica. Questo vuol dire che avendo due pc che contemporaneamente utilizzano questo software, il primo che tra i due avvia la modifica di un record, deve "bloccare" quel record in modo che quando e se, con la seconda istanza del programma, si tenterà di modificare lo stesso record, verrà mostrato un normalissimo messaggio e venga interrotta la procedura.
Come dbms utilizzo MySql e l'unica cosa che sono riuscito a fare é quella di bloccare il record con "START TRANSACTION" fino a quando non faccio COMMIT o chiudo la connessione. Il problema è che non so come verificare se vi è una transazione attiva o un qualche tipo di blocco per interrompere la procedura e questo comporta che la seconda istanza del programma resta completamente bloccata fin quando non sblocco il record dalla prima istanza. Soluzioni? Grazie per l'attenzione.

Inviato dal mio GT-I9300 con Tapatalk 2

[gugoXX]

La gestione mediate transaction che stai facendo e' corretta.

Potresti pero' far fare le modifiche a partire da un altro Thread in background, cosi' non bloccherai la GUI e il secondo thread entrante attendera' che la transazione del primo sia finita.

Se la parte di applicativo e' il classico "leggo e faccio vedere la tabella e permetto l'aggiornamento" allora
aggiungerei il classico "Last_Modified" o una qualche sequence come colonna aggiuntiva della tabella in questione.
Ogni qual volta si aggiunge/inserisce un record nella tabella si deve gestire anche il last_modified o la sequence.
Colui che prende controllo del record, subito dopo avere aperto la transazione deve controllare che il campo della sequence corrisponda a quanto da lui ottenuto in fase di lettura precedente di questo specifico record
Se sono diversi significa che il record e' stato nel frattempo aggiornato da qualche altro client. E occorrerebbe interrompere l'aggiornamento perche' si e' in possesso di dati staled e l'utente ha eventualmente compiuto decisioni errate.
Si potrebbe a questo punto richiedere i dati nuovi, rinfrescare l'immagine della tabella del client e si puo' chiedere all'utente di reinserire i dati.

[rizzotti91]

Ciao e grazie per la risposta.
Il problema è che se io (primo pc) faccio START TRANSACTION e comincio a modificare quel record, me lo ritrovo bloccato, come è corretto che sia, se però il record da modificare è lungo e vengo interrotto nel mezzo della modifica, o semplicemente mi scordo che lo stavo modificando, questo record resta bloccato anche per mezz'ora. Dall'altra parte (secondo pc), il software tenta di avviare la transazione ed il software si blocca completamente, fino a quando, dopo 55 secondi, innodb va in timeout e compare l'eccezione di timeout... possibile che non ci sia il modo di vedere SUBITO se quel record è attualmente bloccato?

[gugoXX]

Mi sa che e' meglio che lasci stare un'architettura 2 livelli e metti un server in mezzo.
Questo server potra' notificare quando un record e' bloccato e quando sara' sbloccato a tutti i sottoscrittori, facendo vedere on-screen qualcosa al volo (Es i record bloccati vengono messi con background giallo e ci si impedisce a priori il focus nei propri campi).

Altrimenti, qualunque cosa tu metta per capire se "Il record e' stato bloccato" avrebbe side effect di multithreading.
1. Tu Controlli che sia bloccato
2. Non e' bloccato
3. Arriva Io e lo blocco ora
4. Tu cerchi di partire e ti ritrovi bloccato con il timeout.

[WarDuck]

Domanda: ma i DB non dovrebbero gestire in maniera nativa la concorrenza?

[rizzotti91]

Originariamente inviato da gugoXX

Mi sa che e' meglio che lasci stare un'architettura 2 livelli e metti un server in mezzo.
Questo server potra' notificare quando un record e' bloccato e quando sara' sbloccato a tutti i sottoscrittori, facendo vedere on-screen qualcosa al volo (Es i record bloccati vengono messi con background giallo e ci si impedisce a priori il focus nei propri campi).

Altrimenti, qualunque cosa tu metta per capire se "Il record e' stato bloccato" avrebbe side effect di multithreading.
1. Tu Controlli che sia bloccato
2. Non e' bloccato
3. Arriva Io e lo blocco ora
4. Tu cerchi di partire e ti ritrovi bloccato con il timeout.

Grazie per la risposta, mi sembra che possa essere una soluzione valida per ME. Il server, nello specifico, chi è? Quello che contiene il database mysql? E se si, cosa dovrebbe fare?

[gugoXX]

Originariamente inviato da WarDuck

Domanda: ma i DB non dovrebbero gestire in maniera nativa la concorrenza?

Infatti, e anche in questo caso il DB server sta facendo ottimamente il suo lavoro.

Originariamente inviato da rizzotti91

Grazie per la risposta, mi sembra che possa essere una soluzione valida per ME. Il server, nello specifico, chi è? Quello che contiene il database mysql? E se si, cosa dovrebbe fare?

Il Server lo devo scrivere tu, e lo potrai mettere anche sulla macchina dove c'e' il DB, ma non e' il DB.
E' un altro componente. Potresti appoggiarti ad IIS e scrivere un servizio web, oppure potresti scrivere un Windows Service, come quelli che appaiono nel pannello di controllo -> Servizi

[rizzotti91]

Originariamente inviato da gugoXX

Infatti, e anche in questo caso il DB server sta facendo ottimamente il suo lavoro.



Il Server lo devo scrivere tu, e lo potrai mettere anche sulla macchina dove c'e' il DB, ma non e' il DB.
E' un altro componente. Potresti appoggiarti ad IIS e scrivere un servizio web, oppure potresti scrivere un Windows Service, come quelli che appaiono nel pannello di controllo -> Servizi

Ed il compito di questo server quale sarà?
PS mio padre che è un programmatore di vecchia data del linguaggio Clipper, mi diceva che in Clipper c'è l'istruzione RLOCK che fa il tutto, possibile che in linguaggi così avanzati come il C# non sia presente?

[gugoXX]

Originariamente inviato da rizzotti91

Ed il compito di questo server quale sarà?
PS mio padre che è un programmatore di vecchia data del linguaggio Clipper, mi diceva che in Clipper c'è l'istruzione RLOCK che fa il tutto, possibile che in linguaggi così avanzati come il C# non sia presente?

Come ti ho gia' detto, qualsiasi soluzione come la RLOCK o simili e' fondamentalemente errata.
Un programma con un RLOCK sara' fatto piu' o meno cosi'

1) Utente tenta di editare un campo
2) RLOCK per vedere se il record e' locked
3) Se non e' locked permetto di editare il campo

Ma in ambiente multitasking puo' capitare
1) Utente tenta di editare un campo
2) RLOCK per vedere se il record e' locked
2B) <<< Qui, immediatamente dopo il mio tentativo di RLOCK entra un altro attore a fare il lock sul record.
3) Se non e' locked permetto di editare il campo
3B) <<< Io qui fallisco, perche' oramai il record e' locked.

Il compito del server sara' quello, fra le altre cose, di fungere da proxy per l'aggiornamento dei campi.
Essenzialmente il server funge da brodcast di messaggi per indicare quali record sono liberi e quali sono invece locked.
Prima di editare un campo di un record libero, dico a questo server che mi riservo il compito di bloccare quel record.
Il server restituisce OK o KO a seconda che il record sia effettivamente libero.
Il server inoltre eventualmente (feature aggiuntiva carina) propaga questa informazione a tutti i client in ascolto, che saranno liberi di usare questa informazione come vogliono (Magari dipingendo di giallo i record bloccati)
Quando ho finito di usare un record, allora diro' al server che non ho piu' intenzione di usarlo.
Il server di nuovo eventulamente in broadcast segnalera' a tutti i clienti in ascolto che il record e' libero (Ridipingendo i record del colore "libero")

2 metodi quindi:
public bool Lock(int RecordNum)
Che resitutisce true o false a seconda che io sia riuscito a riservare il record per me oppure no
public void Unlock(int RecordNum)
per sbloccare il record in questione.

Ovviamente il codice di questi metodi deve essere gestito in regione critica, tutto essenzialmente dentro una lock

[rizzotti91]

EDIT.

[WarDuck]

Originariamente inviato da gugoXX

Infatti, e anche in questo caso il DB server sta facendo ottimamente il suo lavoro.

Intendo dire, occorre usare esplicitamente il costrutto delle TRANSACTION?

[!fazz]

Originariamente inviato da rizzotti91

Ciao e grazie per la risposta.
Il problema è che se io (primo pc) faccio START TRANSACTION e comincio a modificare quel record, me lo ritrovo bloccato, come è corretto che sia, se però il record da modificare è lungo e vengo interrotto nel mezzo della modifica, o semplicemente mi scordo che lo stavo modificando, questo record resta bloccato anche per mezz'ora. Dall'altra parte (secondo pc), il software tenta di avviare la transazione ed il software si blocca completamente, fino a quando, dopo 55 secondi, innodb va in timeout e compare l'eccezione di timeout... possibile che non ci sia il modo di vedere SUBITO se quel record è attualmente bloccato?

ma scusa tu stai modificando a mano il db?

a questo punto non fai prima a preparare a parte la query di modifica così ti basta lanciarla con la sua transazione e non devi lasciarla aperta mezzora?

[rizzotti91]

Originariamente inviato da gugoXX

Come ti ho gia' detto, qualsiasi soluzione come la RLOCK o simili e' fondamentalemente errata.
Un programma con un RLOCK sara' fatto piu' o meno cosi'

1) Utente tenta di editare un campo
2) RLOCK per vedere se il record e' locked
3) Se non e' locked permetto di editare il campo

Ma in ambiente multitasking puo' capitare
1) Utente tenta di editare un campo
2) RLOCK per vedere se il record e' locked
2B) <<< Qui, immediatamente dopo il mio tentativo di RLOCK entra un altro attore a fare il lock sul record.
3) Se non e' locked permetto di editare il campo
3B) <<< Io qui fallisco, perche' oramai il record e' locked.

Il compito del server sara' quello, fra le altre cose, di fungere da proxy per l'aggiornamento dei campi.
Essenzialmente il server funge da brodcast di messaggi per indicare quali record sono liberi e quali sono invece locked.
Prima di editare un campo di un record libero, dico a questo server che mi riservo il compito di bloccare quel record.
Il server restituisce OK o KO a seconda che il record sia effettivamente libero.
Il server inoltre eventualmente (feature aggiuntiva carina) propaga questa informazione a tutti i client in ascolto, che saranno liberi di usare questa informazione come vogliono (Magari dipingendo di giallo i record bloccati)
Quando ho finito di usare un record, allora diro' al server che non ho piu' intenzione di usarlo.
Il server di nuovo eventulamente in broadcast segnalera' a tutti i clienti in ascolto che il record e' libero (Ridipingendo i record del colore "libero")

2 metodi quindi:
public bool Lock(int RecordNum)
Che resitutisce true o false a seconda che io sia riuscito a riservare il record per me oppure no
public void Unlock(int RecordNum)
per sbloccare il record in questione.

Ovviamente il codice di questi metodi deve essere gestito in regione critica, tutto essenzialmente dentro una lock

RLOCK è per bloccare il record: se quel record è libero viene subito bloccato, quindi non c'è la possibilità che un altro vi possa accedere. Siccome RLOCK ritorna vero o falso, so che se mi torna vero, vuol dire che l'ha bloccato, se è falso è già bloccato e quindi si può far comparire un messaggio, del tipo "Record bloccato, ritenti o no?", se si sceglie si, riparte il ciclo, in caso contrario non succede nulla... è quello che vorrei ricreare io...

[rizzotti91]

Originariamente inviato da !fazz

ma scusa tu stai modificando a mano il db?

a questo punto non fai prima a preparare a parte la query di modifica così ti basta lanciarla con la sua transazione e non devi lasciarla aperta mezzora?

Mi devi scusare, non ho capito nulla della tua risposta, ma cosa ben più grave, tu non hai capito quello che ho scritto io, un po' come tutti quelli che stanno rispondendo a questa discussione, fatta eccezione per gugoXX.
Quando io non capisco un quesito, o non sono in grado di rispondere, mi astengo dal farlo, sarebbe cosa gradita che tutti gli utenti del forum rispettassero questa semplice regola.

[!fazz]

Originariamente inviato da rizzotti91

Mi devi scusare, non ho capito nulla della tua risposta, ma cosa ben più grave, tu non hai capito quello che ho scritto io, un po' come tutti quelli che stanno rispondendo a questa discussione, fatta eccezione per gugoXX.
Quando io non capisco un quesito, o non sono in grado di rispondere, mi astengo dal farlo, sarebbe cosa gradita che tutti gli utenti del forum rispettassero questa semplice regola.

Se invece di flammare con chi sta cercando di aiutarti ti saresti preso la briga di capire quello che volevo dirti forse risolveresti i tuoi problemi in meno tempo no?

mica ho scritto io che tengo attiva una transazione anche per mezzora perchè ti dimentichi quello che stavi facendo e passi ad altro no? mai e poi mai ho visto transazioni rimanere attive aspettando i comodi dell'utente ovvero, le transazioni servono per evitare una doppia sovrascrittura dei dati causati dall'accesso concorrente in scrittura allo stesso record. il solo fatto che tu le usi in questo modo significa che non hai capito cosa sono e cosa servono; il che porta giusto appunto alla mia risposta precedente ovvero devi bloccare il db per il minor tempo possibile il che significa preparare la query di modifica prima e una volta preparata e pronta si lancia sul db con la sua bella transazione che si chiude subito dopo così hai un lock di qualche ms invece che di mezzora anche se ti dimentichi il lavoro a metà

ps Una semplice regola di buona educazione consisterebbe nel ringraziare gli utenti che perdono il loro prezioso tempo per aiutare gli altri invece che arrogarsi il diritto di prendersela perché costoro hanno in assistenza la sfera di cristallo; dovresti cercare di capire le risposte che si danno visto che, fino a prova contraria quello che ha una minima esperienza con i database e ha problemi sei tu, invece tu ammetti tranquillamente di non aver capito la risposta ma nel contempo l'hai compresa talmente bene da capire che non andava bene, complimenti per la coerenza

[rizzotti91]

Potrò anche sembrare brusco, ma IO sono abituato nel chiedere chiarimenti ad un utente se ho intenzione di aiutarlo e se ne ho le conoscenze. Qui non si mette in dubbio la vostra preparazione, dato che sono io quello che ha bisogno di aiuto e non voi... la cosa che mi scoccia di un po' tutti i forum è che si comincia a sparare a vanvera su quello che è stato richiesto. Se avessi capito la mia domanda (e non devi prenderla come un insulto, perchè non capire non vuol dire essere stupidi), avresti capito che la mia transazione deve durare anche 10 ore.
Per gestionale intendo un software che gestisca una grandissima mole di dati, in aziende in cui gli utenti utilizzatori, non stanno seduti accanto, bensì in luoghi ben separati.Se si hanno quindi 100 utenti che stanno lavorando sul Database, è probabile che l'utente A noti un prezzo sbagliato, mentre l'utente B noti che c'è una lettera sbagliata nella descrizione, ed infine, l'utente C nota che c'è qualcosa che non va nell'esistenza. A quel punto, se facessi come hai detto tu, sempre se ho capito, dovrei far inserire ad A il prezzo corretto, a B la lettera ed a C l'esistenza; si cliccka quindi su "conferma" e si avvia la transazione di un secondo che blocca il record e lo sblocca subito. Bene, se questi tre utenti hanno cliccato contemporaneamente, cosa succederà a quel record? Deve essere una gara a chi clicca più in fretta il tasto Conferma? Non è più logico che se A sta modificando il record, B e C non possono fin quando non finisce?

[!fazz]

Originariamente inviato da rizzotti91

Potrò anche sembrare brusco, ma IO sono abituato nel chiedere chiarimenti ad un utente se ho intenzione di aiutarlo e se ne ho le conoscenze. Qui non si mette in dubbio la vostra preparazione, dato che sono io quello che ha bisogno di aiuto e non voi... la cosa che mi scoccia di un po' tutti i forum è che si comincia a sparare a vanvera su quello che è stato richiesto. Se avessi capito la mia domanda (e non devi prenderla come un insulto, perchè non capire non vuol dire essere stupidi), avresti capito che la mia transazione deve durare anche 10 ore.
Per gestionale intendo un software che gestisca una grandissima mole di dati, in aziende in cui gli utenti utilizzatori, non stanno seduti accanto, bensì in luoghi ben separati.Se si hanno quindi 100 utenti che stanno lavorando sul Database, è probabile che l'utente A noti un prezzo sbagliato, mentre l'utente B noti che c'è una lettera sbagliata nella descrizione, ed infine, l'utente C nota che c'è qualcosa che non va nell'esistenza. A quel punto, se facessi come hai detto tu, sempre se ho capito, dovrei far inserire ad A il prezzo corretto, a B la lettera ed a C l'esistenza; si cliccka quindi su "conferma" e si avvia la transazione di un secondo che blocca il record e lo sblocca subito. Bene, se questi tre utenti hanno cliccato contemporaneamente, cosa succederà a quel record? Deve essere una gara a chi clicca più in fretta il tasto Conferma? Non è più logico che se A sta modificando il record, B e C non possono fin quando non finisce?

a parte che io ti avevo chiesto chiarimenti ("ma scusa tu stai modificando a mano il db? " mi pare che sia una domanda a cui non hai dato risposta ) prima di darti una soluzione su una cosa che è sbagliata di principio (aka la transazione serve per evitare collisioni in fase di scrittura quindi deve essere sempre legata alla sola fase di modifica fisica del record, il che vuol dire che non si deve aspettare nella transazione l'input dell'utente e che quindi non si corre il rischio di dimenticare la transazione bloccata perchè si stà facendo altro) e comunque dalla tua descrizione non posso immaginarmi quanto può durare la transazione (quanti milioni di update fai? )visto che sei tu che parli che ti dimentichi la transazione aperta perchè sei passato ad altro.

non hai capito proprio a cosa servono le transazioni, non prenderlo come un insulto ma non esiste parlare di transazioni, ovvero le transazioni proteggono il db (approposito le transazioni non servono nel caso del tuo esempio in cui 3 utenti cambiono 3 campi diversi dello stesso record, le transazioni servono quando ad esempio l'utente a cambia il prezzo a 5 e l'utente B cambia il prezzo a 10 dello stesso articolo (aka anche senza transazioni non avresti problemi nel gestire un caso come il tuo esempio

comunque è più logico che se un utente modifica qualcosa la modifica vada a buon fine se nessun altro ha modificato la stessa cosa prima di lui. quello che vorresti fare tu è un blocco a livello software delle modifiche ma non si fà con la transazione (o meglio devi usare le transazioni quando scrivi sul db ma il blocco devi farlo a livello superiore) tu hai un problema a livello applicativo che stai tentando di risolvere solo a livello di dbms

quindi assodato che è sbagliato bloccare un record per tutta la durata dell'operazione hai due strade (che entrambe comportano il lock minimale del db )

1) usi un campo per contenere lo stato del record, quando vuoi modificare il record la prima cosa che fà il sistema è, usando la transazione cambiare lo stato del record ) e gestire la concorrenza degli utenti direttamente da software lasciando il db libero di girare (il primo utente che prova accede alla modifica agli altri viene risposto picche fino a che non ha terminato)

2) leggi i dati e popoli la maschera, alla conferma controlli se i dati letti in precedenza sono ancora validi o meno e in caso affermativo procedi con la modifica ma ovvviamente controlli solo quelli che hai modificato (ovvero cambi il prezzo e controlli se il prezzo non è stato alterato da altri chissenefrega se qualcuno ha modificato la descrizione)

la soluzione due mi pare che sia quella che sia quella più elegante e funzionale comunque ti consiglio bene di riguardare la documentazione relativa alle transazioni perchè non fanno quello per cui vuoi utilizzarle, lo scopo delle transazioni lo vedi bene con la seconda modalità che ti ho spiegato prima ovvero ipotizza che nella tua maschera tu voglia modificare prezzo e descrizione del prodotto

inizi la transazione

controlli se il prezzo è rimasto invariato (ok)
update prezzo....
controlli se la descrizione è invariata (orrore qualcuno l'ha modificata)
rollback

e le tue modifiche sul db vengono annullate, ritorni alla maschera e gestisci l'evento

[rizzotti91]

So che le transazioni dovrebbero essere utilizzate per altri scopi, come per esempio per vere e proprie transazioni bancarie, in modo da poter ricorrere al ROLLBACK. Il problema è che non so come posso bloccare un record e se il DBMS permetta di farlo (un po' come avviene con le transazioni) e se questo avviene, com'è possibile rilevarlo da dentro il programma (esiste una qualche query??).

Per il fatto che sia più o meno giusta la mia soluzione, la questione non riguarda il numero di modifiche che vengono effettuate, però ti parlo davvero di decine di utenti che lavorano contemporaneamente ad un database e se io comincio a modificare, tu non devi poter far altro che effettuare ricerche, inserimento e visualizzazione, quel record non lo puoi toccare, anche perchè se io lo sto stravolgendo, cliccko conferma, e "tu" nel frattempo avevi modificato una fesseria e cliccki conferma dopo di me, mi sovrascriverai tutte le modifiche da me effettuate e non è una cosa che posso permettermi accada.

Per quanto riguarda un'eventuale gestione software, la cosa a cui avevo pensasto, come da altri suggerito, è una campo di tipo timestamp in ogni tabella, in modo da sapere data/ora della modifica... all'inizio controllo questo valore e lo memorizzo in una variabile, effettuo le varie modifiche, passano i minuti o le ore necessarie e prima di effettuare la query di inserimento, controllo se quel valore nel db è diverso rispetto a quello che ho memorizzato, in tal caso farò apparire un messaggio o una qualsiasi altra cosa. Mi vengono in mente due problemi però:
A) Se i pc hanno date diverse tra loro? O se anche i minuti fossero di poco "sballati"?
B) Lo vedo un po' inutile farti cominciare a modificare ed a scrivere un bel po' di cose, se tanto l'utente che arriva dopo 5 minuti, modifica una caxxata e ciò comporta il farti comparire il messaggio "Il record è stato modificato, confermi i dati da te inseriti o vuoi ricaricare le informazioni?". Cioè se sei a distanza dall'utente che ha effettuato la modifica, non è neanche molto comodo restare in attesa e chiedere "Ehi cosa hai modificato? Posso sovrascrivere e ri-modifichi?", non so se mi spiego... vorrei bloccare la cosa a monte...

Eppure facendo ricerche ho visto che questo approccio che voglio adottare è quello definito "pessimistico" e che è sconsigliato... ma è sconsigliato per quali motivi? Una situazione del genere come andrebbe gestita allora? Ha più importanza l'ultima modifica?

PS scusami per il post di prima e grazie comunque per l'interessamento.

[!fazz]

Originariamente inviato da rizzotti91

So che le transazioni dovrebbero essere utilizzate per altri scopi, come per esempio per vere e proprie transazioni bancarie, in modo da poter ricorrere al ROLLBACK. Il problema è che non so come posso bloccare un record e se il DBMS permetta di farlo (un po' come avviene con le transazioni) e se questo avviene, com'è possibile rilevarlo da dentro il programma (esiste una qualche query??).

te la puoi fare su un campo di stato
Per il fatto che sia più o meno giusta la mia soluzione, la questione non riguarda il numero di modifiche che vengono effettuate, però ti parlo davvero di decine di utenti che lavorano contemporaneamente ad un database e se io comincio a modificare, tu non devi poter far altro che effettuare ricerche, inserimento e visualizzazione, quel record non lo puoi toccare, anche perchè se io lo sto stravolgendo, cliccko conferma, e "tu" nel frattempo avevi modificato una fesseria e cliccki conferma dopo di me, mi sovrascriverai tutte le modifiche da me effettuate e non è una cosa che posso permettermi accada.
la modalità di gestione le collisioni le decidi tu nel software in base a quello che vuoi fare e nella modalità che più ti aggrada

Per quanto riguarda un'eventuale gestione software, la cosa a cui avevo pensasto, come da altri suggerito, è una campo di tipo timestamp in ogni tabella, in modo da sapere data/ora della modifica... all'inizio controllo questo valore e lo memorizzo in una variabile, effettuo le varie modifiche, passano i minuti o le ore necessarie e prima di effettuare la query di inserimento, controllo se quel valore nel db è diverso rispetto a quello che ho memorizzato, in tal caso farò apparire un messaggio o una qualsiasi altra cosa. Mi vengono in mente due problemi però:
A) Se i pc hanno date diverse tra loro? O se anche i minuti fossero di poco "sballati"?

invece dei timestamp usa un nome utente così risolvi eventuali problemi di sync
B) Lo vedo un po' inutile farti cominciare a modificare ed a scrivere un bel po' di cose, se tanto l'utente che arriva dopo 5 minuti, modifica una caxxata e ciò comporta il farti comparire il messaggio "Il record è stato modificato, confermi i dati da te inseriti o vuoi ricaricare le informazioni?". Cioè se sei a distanza dall'utente che ha effettuato la modifica, non è neanche molto comodo restare in attesa e chiedere "Ehi cosa hai modificato? Posso sovrascrivere e ri-modifichi?", non so se mi spiego... vorrei bloccare la cosa a monte...
Imho se lavori a livelo di singoli campi ti levi dalle scatole questo problema ovvero se uno ha modificato un altro campo dello stesso record non c'è il minimo problema la collisione accade quando 2 utenti modificano lo stesso valore e li solo uno può aver ragione (o il prezzo è 5 o il prezzo è 10)
Eppure facendo ricerche ho visto che questo approccio che voglio adottare è quello definito "pessimistico" e che è sconsigliato... ma è sconsigliato per quali motivi? Una situazione del genere come andrebbe gestita allora? Ha più importanza l'ultima modifica?
è sconsigliato perchè fai un blocco troppo pesante e blocchi anche operazioni completamente lecite (il classico esempio di prima se tu modifichi il prezzo blocchi la possibilità ad un altro utente di cambiare in contemporanea la descrizione magari con 100 utenti si risolve con una pausa caffè al giorno in più nell'attesa che qualcun altro finisca ma con 200.000 utenti in contemporanea le inefficienze aumentano, non ha più importanza l'ultima modifica ne ha più importanza la prima quello importante è che non ci sia il caso di due scritture dello stesso dato concorrenti non gestite (quindi bisogna sapere di chi sarà la modifica registrata, la mia, la tua o quella di un altro sarà compito dell'applicazione e non del db gestire la collisione: potresti dare più importanza alla prima modifica, all'ultima, potresti chiedere ogni volta conferma o andare a priorità a seconda degli utenti, dipende dalla logica che implementi ma come ho detto prima l'importante è mantenere la conoscenza
PS scusami per il post di prima e grazie comunque per l'interessamento.

di niente ma la prossima volta un approccio più calmo al forum sarebbe preferibile