Simultaneidade do cursor (Mecanismo de Banco de Dados)

O Microsoft SQL Server dá suporte a quatro opções de simultaneidade para cursores de servidor:

• READ_ONLY

• OPTIMISTIC WITH VALUES

• OPTIMISTIC WITH ROW VERSIONING

• SCROLL LOCKS

• READ_ONLY
  Não são permitidas atualizações posicionadas pelo cursor e não é mantido nenhum bloqueio nas linhas que compõem o conjunto de resultados.

• OPTIMISTIC WITH VALUES
  Controle de simultaneidade otimista é uma parte padrão de teoria de controle de transação. O controle de simultaneidade otimista é usado em situações quando há somente uma pequena chance de que outro usuário ou processo possa atualizar uma linha no intervalo quando um cursor é aberto e quando a linha é atualizada. Quando um cursor é aberto com essa opção, nenhum bloqueio é mantido nas linhas subjacentes, que ajuda a maximizar a taxa de transferência. Se o usuário tentar modificar uma linha, os valores atuais na linha serão comparados com os valores recuperados na última busca da linha. Se qualquer um dos valores for alterado, o servidor saberá que outro usuário ou processo já atualizou a linha e retornará um erro. Se os valores forem os mesmos, o servidor executará a modificação.

  A seleção dessa opção de simultaneidade força o usuário ou programador a aceitar a responsabilidade de lidar com o erro ocasional, que indica que outro usuário modificou a linha. Uma ação típica assumida por um aplicativo que recebe esse erro é atualizar o cursor, obter os valores novos e, depois, permitir que o usuário opte por executar a modificação nos valores novos. Colunas text, ntext e image não são usadas em comparações de simultaneidade na versão 6.5 ou anteriores do SQL Server.

• OPTIMISTIC WITH ROW VERSIONING
  Essa opção de controle de simultaneidade otimista baseia-se em versão de linha. Com a versão de linha, a tabela subjacente deve ter um identificador de versão de algum tipo que o servidor possa usar para determinar se a linha foi alterada depois de lida no cursor. No SQL Server, essa capacidade é fornecida pelo tipo de dados timestamp, que é um número binário que indica a seqüência relativa de modificações em um banco de dados. Cada banco de dados tem um valor de carimbo de data/hora atual global, **@@**DBTS. Sempre que uma linha com uma coluna timestamp é modificada, o SQL Server armazena o valor atual **@@**DBTS na coluna timestamp e incrementa **@@**DBTS. Se uma tabela tiver uma coluna timestamp, os carimbos de data/hora descerão até o nível de linha. O servidor pode comparar o valor atual do carimbo de data/hora de uma linha com o valor de carimbo de data/hora armazenado na última busca da linha para determinar se ela foi atualizada. O servidor não precisa comparar os valores em todas as colunas, somente na coluna timestamp. Se um aplicativo solicita simultaneidade otimista com versão de linha em uma tabela que não tem uma coluna timestamp, o cursor assumirá como padrão um controle de simultaneidade otimista com base em valores.

  Observação
  Para cursores abertos em fontes de dados remotas, não haverá suporte para as atualizações pelo cursor se a fonte remota não contiver uma coluna de carimbo de data/hora.

• SCROLL LOCKS
  Essa opção implementa controle de simultaneidade pessimista, no qual o aplicativo tenta bloquear as linhas de banco de dados subjacentes no momento em que são lidas no conjunto de resultados de cursor. Ao usar cursores de servidor, será feito um bloqueio de atualização na linha quando o cursor for lido. Se o cursor for aberto em uma transação, o bloqueio de atualização da transação será mantido até que a transação seja confirmada ou revertida; um bloqueio de cursor será descartado quando a próxima linha for encontrada. Se o cursor tiver sido aberto fora de uma transação, o bloqueio será descartado quando a próxima linha for encontrada. Portanto, um cursor deve ser aberto em uma transação sempre que o usuário desejar controle de simultaneidade pessimista completo. Um bloqueio de atualização impede qualquer outra tarefa de adquirir uma atualização ou bloqueio exclusivo, o que impede qualquer outra tarefa de atualizar a linha. Entretanto, um bloqueio de atualização não bloqueia um bloqueio compartilhado, portanto, ele não impede outras tarefas de ler a linha a menos que a segunda tarefa também esteja solicitando uma leitura com um bloqueio de atualização.