pessimistica rispetto Optimistic Concurrency (Blocco contro Feedback)

Question

Sto costruendo un programma con i seguenti criteri:

• elementi di lavoro: elementi che devono essere lavorato manualmente via web dagli utenti (forma abbreviata di una pagina)
• utenti multipli di lavoro 'elementi di lavoro'
• Ogni utente ha una coda di 'elementi di lavoro'
• C'è una ricerca che permette agli utenti di visualizzare 'gli elementi di lavoro' e assegnare 'elementi di lavoro nei confronti dei loro code
• Utenti può prendere "oggetti di lavoro" dalle code degli altri assegnandoli a se stessi

Nota: gli "elementi di lavoro" vengono elaborati 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''oggetto di lavoro' è funzionato, è andato via dal sistema (a parte qualche auditing/reporting), un po 'come un sistema di tracciamento dei bug

Quale opzione credi sia meglio? Puoi citare alcune applicazioni tradizionali che supportano la tua opinione?

Opzione 1:

• Quando l'utente A va a visualizzare o lavorare un 'elemento di lavoro', il 'elemento di lavoro' viene bloccato.
• Quando gli altri utenti passano all '"elemento di lavoro" dopo che l'utente A ha aperto l' "oggetto di lavoro", saranno in grado di vedere solo l '"oggetto di lavoro". Non possono scrivere.
• Il blocco scade dopo n minuti, momento in cui un altro utente può bloccare l'elemento di lavoro.

Opzione 2:

• Qualsiasi utente può tirare su un 'elemento di lavoro' senza bloccarlo.
• Se l'utente A lavora l'elemento di lavoro inviando il modulo e l'utente B lavora lo stesso "oggetto di lavoro", il lavoro dell'utente A avrà effetto nel database e l'utente B verrà informato che le modifiche non sono state eseguite influisce perché un altro utente ha modificato "l'oggetto di lavoro".

Personalmente preferisco l'opzione 2. Pensieri per favore?

Answer 1

Sembra che tu stia parlando del controllo di concorrenza optimistic versetti .

Entrambi sono ampiamente utilizzati, personalmente trovo che la concorrenza ottimistica sia più facile da gestire, ma dipenderà dalle vostre esigenze e dal vostro utilizzo. Se le modifiche (e potenziali conflitti) sono comuni, il controllo della concorrenza pessimista può essere appropriato, se non lo è, allora la concorrenza ottimistica sarà più veloce e più semplice con cui lavorare.

Fatemi sapere se volete vedere esempi di codice che utilizzano RowVersion tipo di dati in SQL Server (che è quello che sto attualmente in uso), è abbastanza semplice però:

• Tutte le tabelle includono colonna RowVersion
• Tutto 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 vengono restituite 0 righe, quindi qualcun altro ha toccato la riga, non viene eseguito 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, in modo simile al ritorno dell'ID di una colonna Identity dopo un inserimento.

Answer 2

Personalmente vorrei andare con l'opzione 2, inoltre, se applicabile (ad esempio quelle modifiche sono su un testo più lungo), è responsabilità dell'utente B unire le modifiche. Dai a B uno strumento per farlo.

Answer 3

Non so come descrivere la forma in termini semplici, ma la sua non una pagina di comunità , è una cosa di una volta. Ipoteticamente, supponiamo che l'utente avesse per abbinare il nome John DOEE a uno di il seguente John Doe Jon Do Once ha funzionato, la modifica è completa. In nostro caso, non avremmo bisogno di mera

Considerando che un commento, vorrei andare con l'opzione 1. Considerando che questi cambiamenti sono uno cambi di tempo, non v'è alcun beneficio per permettere a più persone di lavorare sullo stesso modificare. Stai solo sprecando il tempo della seconda persona.