Concorrenza pessimistica vs ottimistica (blocco contro feedback)

Question

Sto creando un'applicazione con i seguenti criteri:

• elementi di lavoro: elementi che devono essere gestiti manualmente via Web dagli utenti (un breve modulo di una pagina)
• Più utenti che lavorano "elementi di lavoro"
• Ogni utente ha una coda di "elementi di lavoro"
• Esiste una ricerca che consente agli utenti di visualizzare "elementi di lavoro" e assegnare "elementi di lavoro" alle loro code
• Gli utenti possono estrarre gli "oggetti di lavoro" dalle code di altre persone assegnandoli a se stessi

Nota: gli "elementi di lavoro" funzionano una sola volta. Questa non è una pagina wiki, è più un esercizio di abbinamento che dovrebbe essere eseguito solo una volta da un utente. Una volta che l'elemento di lavoro è funzionato, viene rimosso dal sistema (a parte alcuni controlli / rapporti), un po 'come un sistema di tracciamento dei bug

Quale opzione ritieni sia migliore? Puoi citare qualche applicazione tradizionale che supporti la tua opinione?

Opzione 1:

• Quando l'utente A visualizza o lavora un "oggetto di lavoro", l '"oggetto di lavoro" viene bloccato.
• Quando altri utenti accedono all '"oggetto di lavoro" dopo che l'utente A ha aperto l' "oggetto di lavoro", potranno vedere solo l '"oggetto di lavoro". Non possono scrivere.
• Il blocco scade dopo n minuti, a quel punto un altro utente può bloccare l '"oggetto di lavoro".

Opzione 2:

• Qualsiasi utente può estrarre un "oggetto di lavoro" senza bloccarlo.
• Se l'utente A funziona "oggetto di lavoro" inviando il modulo e l'utente B funziona lo stesso "oggetto di lavoro", il lavoro dell'utente A avrà effetto nel database e l'utente B verrà informato che le modifiche non hanno preso influenza perché un altro utente ha modificato l '"elemento di lavoro".

Personalmente mi piace l'opzione 2. Pensi per favore?

Answer 1

Sembra che tu stia parlando di pessimistic versi ottimista controllo della concorrenza.

Entrambi sono ampiamente utilizzati, personalmente trovo che la concorrenza ottimistica sia più facile da gestire, ma dipenderà dalle tue esigenze e dal tuo utilizzo. Se le modifiche (e i potenziali conflitti) sono comuni, allora il controllo pessimistico della concorrenza potrebbe essere appropriato, in caso contrario, la concorrenza ottimistica sarà più veloce e più semplice con cui lavorare.

Fammi sapere se vuoi vedere esempi di codice usando RowVersion tipo di dati in SQL Server (è quello che sto attualmente utilizzando), è piuttosto semplice però:

• Tutte le tabelle includono la colonna RowVersion
• Tutte le query SELECT includono questa colonna (per i dati che possono essere modificati)
• Tutte le query UPDATE o DELETE includono WHERE RowVersion = @RowVersion. Questa è la parte ottimistica, se 0 righe sono state restituite, qualcun altro ha toccato la riga, non ha luogo alcun aggiornamento, quindi informa l'utente. NOTA: se la riga è stata aggiornata, è necessario restituire anche il nuovo valore per RowVersion. Questo vale anche per le query INSERT, proprio come si restituirebbe l'ID di una colonna di identità dopo un inserimento.

Answer 2

  

Non sono sicuro di come descrivere il modulo in   termini semplici, ma non è una comunità   pagina, è una cosa sola.   Ipoteticamente, supponiamo che l'utente abbia avuto   per abbinare il nome John DOEE a uno di   il seguente John Doe Jon Do Once   ha funzionato, la modifica è completa. Nel   nel nostro caso, non dovremmo semplicemente

Considerando quel commento, andrei con l'opzione 1. Considerando che questi cambiamenti sono cambiamenti di una volta, non vi è alcun vantaggio nel consentire a più persone di lavorare sullo stesso cambiamento. Stai solo perdendo il tempo della seconda persona.

Answer 3

Personalmente andrei con l'opzione 2 - in più, se applicabile (per esempio quelle modifiche sono su un testo più lungo) renderebbe la responsabilità dell'utente B di unire le modifiche. Dai a B uno strumento per farlo.