Pessimista vs simultaneidade optimista (Fecho contra feedback)

Question

Estou construindo uma aplicação com os seguintes critérios:

• itens de trabalho: itens que precisam ser trabalhados manualmente através da web pelos usuários (curta uma forma página)
• Vários usuários trabalho dos itens de trabalho '
• Cada usuário tem uma fila de 'itens de trabalho'
• Há uma busca que permite aos usuários vista dos itens de trabalho "e 'itens de trabalho' atribuir a suas filas
• Os usuários podem tirar de filas de outras pessoas 'itens de trabalho', atribuindo-lhes a si próprios

Nota: 'itens de trabalho' são trabalhados apenas uma vez. Esta não é uma página de wiki, é mais de um exercício correspondente que deve ser realizada apenas uma vez por um usuário. Uma vez que o 'item de trabalho' é trabalhado, ele está desaparecido desde o sistema (com exceção de alguns de auditoria / relatórios), um pouco como um sistema de rastreamento de bugs

Qual opção você acha que é melhor? Você pode citar quaisquer aplicações tradicionais que apoiam a sua opinião?

Opção 1:

• Quando o usuário A vai para ver ou trabalhar um 'item de trabalho', o 'item de trabalho' fica bloqueado.
• Quando outros usuários ir para o 'item de trabalho' depois de o utilizador A abre o 'item de trabalho', eles só serão capazes de ver o 'item de trabalho'. Eles não podem escrever.
• O bloqueio expira após n minutos altura em que outro usuário pode bloquear o 'item de trabalho'.

Opção 2:

• Qualquer usuário pode puxar para cima um 'item de trabalho' sem bloqueá-lo.
• Se o usuário A trabalha o 'item de trabalho' por enviar o formulário e usuário B funciona da mesma 'item de trabalho', então o trabalho do usuário A terá efeito no banco de dados e usuário B será informado de que suas mudanças não levou afetar porque outro usuário modificou o 'item de trabalho'.

Eu, pessoalmente, como opção 2. Pensamentos por favor?

Answer 1

Parece que você está falando sobre pessimista versos controle simultaneidade otimista.

Ambos são amplamente utilizados, pessoalmente acho concorrência otimista mais fácil de lidar, mas vai depender de suas próprias necessidades e uso. Se as edições (e potenciais conflitos) são comuns em seguida, controle de simultaneidade pessimista pode ser apropriada, se não, então simultaneidade otimista será mais rápido e mais simples de trabalhar com ele.

Deixe-me saber se você quiser ver exemplos de código usando RowVersion tipo de dados em SQL Server (que é o que eu estou usando atualmente), é bastante simples, porém:

• Todas as tabelas incluem coluna RowVersion
consultas
• Escolha incluir esta coluna (para dados que podem ser modificados)
• Todos UPDATE ou consultas de DELETE incluem um WHERE RowVersion = @RowVersion. Esta é a parte otimista, se 0 linhas retornou em seguida, alguém tocou a linha, nenhuma atualização ocorre, então diga usuário sobre isso. NOTA: Se linha foi atualizado, então novo valor para RowVersion também devem ser devolvidos. Isto também se aplica para consultas INSERT, assim como você iria retornar o ID de uma coluna de identidade após uma inserção.

Answer 2

Não sei como descrever a forma em termos simples, mas não é uma comunidade página, sua uma coisa do tempo. Hipoteticamente, digamos que o usuário tinha para coincidir com o nome de John DOEE a um dos o seguinte John Doe Jon fazer uma vez é trabalhado, a edição está completa. No nosso caso, não teria necessidade de mera

Considerando que o comentário, eu iria com a opção 1. Considerando que estas mudanças são uma mudança de horário, não há nenhum benefício de permitir que várias pessoas trabalhem na mesma mudança. Você só está perdendo tempo a 2ª pessoa.

Answer 3

Eu, pessoalmente, iria com a opção 2 - Além disso, se não aplicável (por exemplo, essas edições estão em um texto mais longo) tornam a responsabilidade do usuário B para mesclar as edições. Dê B uma ferramenta para fazê-lo.