Optimista vs bloqueio pessimista

Question

Eu entendo as diferenças entre o bloqueio otimista e pessimista. Agora, alguém poderia explicar-me quando eu ia usar qualquer um em geral?

E faz a resposta a esta mudança questão dependendo se ou não, eu estou usando um procedimento armazenado para executar a consulta?

Mas apenas para verificar, meios otimistas "não bloquear a tabela durante a leitura" e meios pessimistas "bloquear a tabela durante a leitura."

Answer 1

bloqueio otimista é uma estratégia onde você lê um registro, tomar nota de um número de versão ( outros métodos para fazer isso envolvem datas, timestamps ou checksums / hashes) e verifique se a versão não mudou antes de escrever a parte de trás registro. Quando escrever a volta registro que você filtrar a atualização da versão para se certificar de que é atômica. (Ou seja, não foi atualizado entre quando você verificar a versão e escrever o registro para o disco) e atualizar a versão em uma batida.

Se o registro estiver sujo (ou seja versão diferente para o seu) você abortar a transação eo usuário pode reiniciá-lo.

Esta estratégia é mais aplicável aos sistemas de alto volume e arquiteturas de três camadas em que você não necessariamente manter uma conexão com o banco de dados para a sessão. Nesta situação, o cliente não pode realmente manter bloqueios de banco de dados como as conexões são tomadas a partir de uma piscina e você pode não estar usando a mesma conexão de um acesso ao próximo.

Locking pessimista é quando você bloquear o registro para seu uso exclusivo até que você tenha terminado com ele. Ele tem muito a integridade melhor do que o bloqueio otimista, mas exige que você seja cuidadoso com o seu design do aplicativo para evitar Deadlocks . Para usar o bloqueio pessimista você precisa de uma conexão direta com o banco de dados (como normalmente seria o caso em um dois camada de aplicativo cliente servidor) ou um ID da transação disponíveis externamente que pode ser usado independentemente da conexão.

Neste último caso, você abre a transação com o TxID e reconecte usando esse ID. O DBMS mantém os bloqueios e permite que você escolha a sessão de volta através do TxID. Isto é como transações distribuídas usando confirmação de duas fases protocolos (como XA ou < a href = "http://msdn.microsoft.com/en-us/library/ms687120(VS.85).aspx" rel = trabalho "noreferrer"> COM + Transações ).

Answer 2

O bloqueio otimista é usado quando você não espera muitas colisões. Custa menos para fazer uma operação normal, mas se a colisão ocorre você iria pagar um preço mais elevado para resolvê-lo como a transação é abortada.

bloqueio pessimista é usado quando uma colisão é antecipado. As operações que violem a sincronização está simplesmente bloqueado.

Para selecionar mecanismo de travamento adequado, você tem que estimar a quantidade de leituras e gravações e decidir em conformidade.

Answer 3

Optimistic assume que nada vai mudar enquanto você está lendo isso.

pessimista assume que algo vai e assim fechaduras-lo.

Se não é essencial que os dados são perfeitamente ler uso otimista. Você pode obter o 'sujo' estranho ler -. Mas é muito menos propensos a resultar em impasses e similares

A maioria das aplicações web são muito bem com leituras sujas -. Nas raras ocasiões em que os dados não exatamente contagem da próxima recarga faz

Para operações de dados exatos (como em muitas transações financeiras) usar pessimista. É essencial que os dados são lidos com precisão, sem alterações-un mostrado - o bloqueio adicional sobrecarga vale a pena.

padrões do servidor

Oh, e Microsoft SQL para bloqueio de página - basicamente a linha que você está lendo e alguns lados. bloqueio de linha é mais preciso, mas muito mais lento. É muitas vezes vale a pena definir suas transações para ler comprometido ou não de bloqueio para bloqueios Evitar durante a leitura.

Answer 4

Além do que tem sido dito já, deve ser dito que o bloqueio otimista tende a melhorar a concorrência em detrimento da previsibilidade. bloqueio pessimista tende a reduzir a simultaneidade, mas é mais previsível.

Você paga seu dinheiro, etc

Answer 5

Gostaria de pensar de mais um caso quando bloqueio pessimista seria uma escolha melhor.

Para o bloqueio otimista cada participante na modificação de dados deve concordar em usar esse tipo de travamento. Mas se alguém modifica os dados sem cuidar sobre a coluna de versão, isso vai estragar toda a idéia do bloqueio otimista.

Answer 6

Existem basicamente dois maioria das respostas populares. A primeiro basicamente diz

necessidades otimistas de três camadas arquiteturas onde você não necessariamente manter uma conexão com o banco de dados para a sessão enquanto Locking pessimista é quando você bloquear o registro para seu uso exclusivo até que você tenha terminado com ele. Ele tem muito melhor integridade de bloqueio otimista você precisa de uma conexão direta com o banco de dados.

Outra resposta é

otimista (versões) é mais rápido devido à ausência de bloqueio, mas (pessimistas) executa bloqueio melhor quando discórdia é alta e é melhor para evitar o trabalho em vez de descartá-lo e começar de novo.

ou

O bloqueio otimista funciona melhor quando você tem colisões raras

Como ele é colocado nesta página.

Eu criei a minha resposta para explicar como "conexão keep" está relacionado com "baixas colisões".

Para entender qual estratégia é melhor para você, não pensar sobre as transações por segundo seu DB tem apenas a duração de uma única transação. Normalmente, você trasnaction aberta, performa operação e fechar a transação. Este é um pequeno, transação clássica ANSI tinha em mente e multa de fugir com bloqueio. Mas, como você implementar um sistema de reserva de bilhetes, onde muitos clientes reservar os mesmos quartos / assentos ao mesmo tempo?

Você navegar as ofertas, preencha o formulário com muitas opções disponíveis e preços atuais. Ele tem um monte de tempo e as opções podem tornar-se obsoleto, todos os preços inválidos entre você começou a preencher o formulário e clique em "Concordo" botão porque não havia nenhum bloqueio sobre os dados acessados ??e outra pessoa, mais ágil, tem intefered mudando todos os preços e você precisa reiniciar com novos preços.

Você pode bloquear todas as opções que você lê-los, em vez disso. Este é cenário pessimista. Você vê por que é uma porcaria. Seu sistema pode ser derrubado por um único palhaço que simplesmente começa uma reserva e vai fumar. Ninguém pode reservar qualquer coisa antes que ele termine. Seu fluxo de caixa cai para zero. É por isso que, reservas otimistas são usados ??em realidade. Aqueles que demore demasiado tempo necessário reiniciar sua reserva a preços mais elevados.

Nesta abordagem otimista você tem que gravar todos os dados que você lê (como em repetida Leia ) e vêm ao ponto de comprometer com a sua versão dos dados (eu quero comprar ações pelo preço que você exibido nesta citação, não ao preço atual). Neste ponto, a transação ANSI é criado, o que bloqueia a DB, verifica se nada for mudado e commits / aborta sua operação. IMO, este é emulação eficaz de MVCC , que também está associada com CC Otimista e também assume que o seu reiniciado transação em caso de aborto, que é que você vai fazer uma nova reserva. A transação aqui envolve um decisões usuário humano.

Estou longe de compreender como implementar o MVCC manualmente, mas eu acho que transações de execução longa com opção de reinício é a chave para a compreensão do assunto. Corrija-me se estou em qualquer lugar errado. Minha resposta foi motivada por esta Alex Kuznecov capítulo .

Answer 7

Na maioria dos casos, o bloqueio otimista é mais eficiente e oferece maior desempenho. Ao escolher entre bloqueio pessimista e otimista, considere o seguinte:

• bloqueio pessimista é útil se houver uma grande quantidade de atualizações e relativamente altas chances de usuários tentando atualizar dados ao mesmo Tempo. Por exemplo, se cada operação pode atualizar um grande número de registros de cada vez (o banco pode adicionar ganhos de juros a cada conta no final de cada mês), e dois aplicativos estão em execução tais operações, ao mesmo tempo, eles terão conflitos.

• bloqueio pessimista também é mais apropriado em aplicações que contêm pequenas mesas que são atualizados com freqüência. No caso de estes chamados hotspots, os conflitos são tão provável que otimista esforço resíduos de bloqueio em reverter conflitantes transações.

• O bloqueio otimista é útil se a possibilidade de conflitos é muito baixo - há muitos registros, mas relativamente poucos usuários, ou muito poucas atualizações e principalmente as operações do tipo ler

.

Answer 8

Um caso de uso para o bloqueio otimista é ter o seu aplicativo usar o banco de dados para permitir que um de seus fios / hosts para 'reivindicação' uma tarefa. Esta é uma técnica que tem vindo a calhar para mim em uma base regular.

O melhor exemplo que posso pensar é para uma fila de tarefas implementadas usando um banco de dados, com vários segmentos alegando tarefas simultaneamente. Se uma tarefa tem o estatuto de 'Disponível', 'Reivindicado', 'Concluído', uma consulta db pode dizer algo como "Definir status = 'Reivindicado', onde status = 'Disponível'. Se vários segmentos tentam mudar o status desta forma, todos, mas o primeiro segmento irá falhar por causa de dados sujos.

Note que este é um caso de uso envolvendo apenas o bloqueio otimista. Assim como uma alternativa a dizer "O bloqueio otimista é usado quando você não espera muitas colisões", ele também pode ser usado onde você espera colisões, mas quer exatamente uma transação para ter sucesso.