ASP.NET MVC - Concorrenza database

La gestione del concorrenza Nelle applicazioni web, è uno degli argomenti a cui dobbiamo dedicare un po' di tempo di qualità, poiché per la natura stessa dell'applicazione possiamo riscontrare casi in cui più utenti devono interagire con lo stesso elemento.
Di per sé è interazione Non è un problema, il vero problema arriva quando dopo aver modificato o toccato questo elemento è necessario salvarlo nel database e quindi due o più utenti vogliono fare un'azione sullo stesso elemento contemporaneamente, cioè dove la nostra logica deve definire un comportamento per sapere qual è il modo corretto di gestirlo.
Come abbiamo spiegato all'inizio, il concorrenza È quando due o più attori lavorano su un elemento nella nostra applicazione, generando un'azione contro il database.
Caso di concorrenzaPossono sorgere problemi quando le modifiche sono in conflitto, ad esempio: l'utente A ha salvato un valore, ma anche l'utente B in quel momento stava modificando e ha salvato un valore diverso, agli occhi dell'utente A il suo contenuto non è stato modificato e agli occhi del all'utente B non c'era nulla che gli impedisse di fare il suo cambiamento.
Questi tipi di conflitti possono offuscare le prestazioni della nostra applicazione agli occhi dell'utente, quindi dobbiamo valutare se le aree che abbiamo varranno o meno programmare per la concorrenza.
Vediamone un po' tipi di concorrenza, in questo modo possiamo capire un po' di più che tipo di azioni possiamo eseguire nelle nostre applicazioni:
Concorrenza pessimisticaQuesto approccio propone che quando si utilizza il database facciamo un blocco preventivo del registro in uso, con questo evitiamo che più utenti modifichino il valore contemporaneamente, il problema risulta che in ambiente web questo non è possibile utilizzarlo a fondo, poiché non essendoci stati non sappiamo realmente se il lock è stato applicato o rimosso fino a quando non comunichiamo con il server, generando confusione e lentezza nell'uso.
Affluenza ottimisticaQuest'altro approccio invece fa qualcosa di un po' più compatibile con il web, in fase di modifica, prima di salvare nel database verifica che i dati non siano stati modificati dal momento in cui è stata effettuata la lettura, per questo facciamo il confronto dei valori dei record e un campo associato che porta un timestamp con data, ora e secondi per una maggiore precisione.
ASP.NET MVC Non supporta l'approccio pessimistico, quindi dobbiamo lavorare con quello ottimista, per questo dobbiamo fornire alle nostre strutture i campi data per salvare l'ultima volta che è stato modificato, quindi possiamo sapere se il valore è stato modificato dopo aver ottenuto il record e prima di salvarlo, con questo possiamo ottenere un avviso e quindi decidere se sovrascrivere o meno quei valori.
Vediamo un piccolo esempio di codice di come potremmo convalidarlo:

Notiamo quindi che convalidiamo quando facciamo una modifica nel database se il campo è stato modificato dopo che abbiamo fatto la lettura, in caso affermativo solleviamo un'eccezione, con questo saremo in grado di intraprendere le azioni corrispondenti, lasciamo anche spazio per poter lavorare sulle diverse eccezioni che possono essere generate.
Alla fine di questo tutorial sappiamo già qualcosa in più sulla concorrenza nei database e su come risolvere il problema ASP.NET MVC.