Compartilhar via

Controle de simultaneidade

Concorrência é a capacidade de duas transações utilizarem os mesmos dados simultaneamente, e com o aumento do isolamento das transações, geralmente ocorre uma redução na concorrência. Isso ocorre porque o isolamento da transação geralmente é implementado com o bloqueio de linhas e, à medida que mais linhas são bloqueadas, menos transações podem ser concluídas sem serem bloqueadas pelo menos temporariamente por uma linha bloqueada. Embora a simultaneidade reduzida seja geralmente aceita como uma compensação para os níveis de isolamento de transação mais altos necessários para manter a integridade do banco de dados, ele pode se tornar um problema em aplicativos interativos com atividade de leitura/gravação alta que usam cursores.

Por exemplo, suponha que um aplicativo execute a instrução SQL SELECT * FROM Orders. Ele chama SQLFetchScroll para rolar ao redor do conjunto de resultados e permite que o usuário atualize, exclua ou insira pedidos. Depois que o usuário atualiza, exclui ou insere um pedido, o aplicativo confirma a transação.

Se o nível de isolamento for Leitura Repetível, a transação poderá - dependendo de como ela é implementada - bloquear cada linha retornada por SQLFetchScroll. Se o nível de isolamento for Serializável, a transação pode trancar toda a tabela Pedidos. Em ambos os casos, a transação libera seus bloqueios somente quando é confirmada ou revertida. Portanto, se o usuário gastar muito tempo lendo pedidos e muito pouco tempo atualizando, excluindo ou inserindo-os, a transação poderá bloquear facilmente um grande número de linhas, tornando-as indisponíveis para outros usuários.

Esse é um problema mesmo se o cursor for de leitura somente e o aplicativo permitir que o usuário leia apenas os pedidos existentes. Nesse caso, o aplicativo confirma a transação e libera bloqueios quando chama SQLCloseCursor (no modo de confirmação automática) ou SQLEndTran (no modo de confirmação manual).

Esta seção contém os seguintes tópicos.

  • Last updated on