Início / dba / Perguntas / 103425
Accepted
Saeed Neamati
Asked: 2015-06-08 01:26:22 +0800 CST

Acesse exclusivamente uma tabela e evite outras consultas, até mesmo consultas de leitura

  • 772

Estou preso ao definir o nível de isolamento da transação. Aqui está o meu cenário que acontece no aplicativo:

  1. Obter mensagens não processadas (usando o IsProcessingsinalizador)
  2. Defina-os IsProcessingcomo verdadeiros (na RAM) e atualize seus IsProcessingstatus
  3. faça o negócio
  4. Defina-os IsProcessingcomo falsos (na RAM) e atualize seus IsProcessingstatus

Isso funciona bem quando é executado sequencialmente. Mas quando executo várias instâncias do meu aplicativo (simultaneidade), vejo que algumas mensagens são processadas duas ou três vezes. Aqui está o que acontece:

  1. A instância A recebe algumas mensagens não processadas
  2. Enquanto a instância A está definindo IsProcessingcomo verdadeiro na RAM, a instância B recebe algumas mensagens e é provável que ela busque uma ou mais das mensagens que já foram buscadas pela instância A

E isso é o que eu fiz na esperança de evitá-lo:

  1. Iniciar transação (serializável)
  2. Obter mensagens não processadas (usando o IsProcessingsinalizador)
  3. Defina-os IsProcessingcomo verdadeiros (na RAM) e atualize seus IsProcessingstatus
  4. Confirmar transação
  5. faça o negócio
  6. Defina-os IsProcessingcomo falsos (na RAM)
  7. Iniciar transação (serializável)
  8. Atualize seu IsProcessingstatus
  9. Confirmar transação

Não sei por que, mas durante as etapas 1 a 4 , outras instâncias ainda podem realizar consultas de leitura . Isso não é desejado. Quero impedir exclusivamente que qualquer coisa, até mesmo consultas de leitura, sejam executadas na tabela de mensagens durante as etapas 1 a 4.

Como eu posso fazer isso? O que estou perdendo no meu design? O objetivo é garantir que, enquanto uma mensagem estiver na fila para processamento, nenhuma outra instância a processará novamente.

sql-server transaction

1 respostas

  1. Best Answer

    Você será capaz de evitar muitas de suas condições de corrida executando muitas de suas etapas em uma única instrução. Ao usar um TOP()cluse, será possível definir o sinalizador em no máximo uma linha. Ao usar a OUTPUTcluse você pode retornar isso para o aplicativo automaticamente.

    Eu defino uma tabela de teste simples e a preencho:

    create table dbo.T(id int, IsProcessing bit default 0);

insert dbo.T(id) values (1),(2),(3),(4);

    A cláusula de saída precisa de uma variável de tabela para receber os valores alterados:

    declare @U table (id int);

    Um pouco de código de depuração para tornar os estados "antes" e "depois" óbvios:

    select 'Before' as B, * from dbo.T;

    E a própria declaração:

    update top (1) dbo.T
set IsProcessing = 1
OUTPUT INSERTED.id
INTO @U(id)
where IsProcessing = 0;

    E os resultados:

    select 'After' as A, * from dbo.T;
select * from @U;

    Esta é a saída da segunda execução acima.

    B       id  IsProcessing
Before  1   1
Before  2   0
Before  3   0
Before  4   0

A       id  IsProcessing
After   1   1
After   2   1
After   3   0
After   4   0

id 
2

    A linha com id=2passou de IsProcessing=0para IsProcessing=1e que idé retornada na variável de tabela.

    Com esses dados triviais, as linhas são processadas na sequência em que foram criadas. Em um ambiente mais complexo, o otimizador pode escolher qualquer linha que corresponda à cláusula where. Se você tiver um requisito para processar linhas em, digamos, sequência de tempo, será necessária qualificação adicional.

    Não pensei muito nisso, mas acredito que ele funcionará em qualquer nível de isolamento com ou sem transações explícitas.

    É claro que é possível que não haja linhas IsProcessing=0no momento em que a instrução é executada. Nesse caso, a variável de tabela terá zero linhas.

    Para isolar totalmente cada transação da outra, você pode tentar sp_getapplock. Isso adicionará sobrecarga e reduzirá a simultaneidade. Você deve ter cuidado para liberar o bloqueio do aplicativo o mais rápido possível, tanto em cenários de sucesso quanto de falha.

    • 2

relate perguntas