O procedimento armazenado sp_getapplock tem os seguintes valores de retorno:
0: O bloqueio foi concedido com sucesso de forma síncrona.
1: O bloqueio foi concedido com sucesso após aguardar a liberação de outros bloqueios incompatíveis.
-1: A solicitação de bloqueio expirou.
-2: A solicitação de bloqueio foi cancelada.
-3: A solicitação de bloqueio foi escolhida como vítima de deadlock.
-999: Indica uma validação de parâmetro ou outro erro de chamada.
Estou escrevendo um wrapper para chamar sp_getapplock
nossa camada de acesso a dados e quero saber em quais circunstâncias -2 pode ser retornado para que eu possa lançar uma exceção descritiva e útil. É óbvio o que os valores de retorno de -1 e -3 significam e posso facilmente criar condições de teste que fazem com que esses valores sejam retornados. Como eu conseguiria obter um valor de retorno de -2?
Observando a origem do
sp_getapplock
proc wrapper, todos os valores de retorno, exceto -999, se originam dosys.xp_userlock
procedimento armazenado interno subjacente. Aposto que o proc interno retorna um -2 quando a solicitação é cancelada por um evento de atenção (tempo limite de consulta do cliente ou cancelamento de consulta explícita do cliente). No entanto, nenhumsp_getapplock
código adicional é executado após o cancelamento do lote, incluindo aRETURN
instrução. Consequentemente, o código de retorno -2 pode ser retornado internamente, mas não há uma maneira prática de o cliente obter o valor.Supondo que essa teoria esteja correta, não há nenhum valor em traduzir para -2 para uma mensagem mais descritiva, pois foi o cliente que cancelou a solicitação em primeiro lugar.
Vou deixar para Paul confirmar isso percorrendo o código do mecanismo de banco de dados SQL com um depurador :-)
sp_getapplock cria bloqueios em semáforos, não em objetos físicos (por MSDN). Ele só bloqueará outro processo se for sp_getapplock com a mesma string e um modo de bloqueio incompatível.
Portanto, as solicitações de bloqueio seriam canceladas em circunstâncias como: um usuário com privilégios mais altos cancela o bloqueio, um processo do servidor cancela o bloqueio, o usuário executando o procedimento armazenado ou um administrador elimina o processo de bloqueio. Sua descrição pode ser "bloqueio cancelado pelo sistema ou outro usuário". Não tenho certeza de como você determinaria o processo/usuário real que cancelou o bloqueio.
Há um procedimento armazenado de bloqueio de aplicativo de lançamento correspondente chamado sp_releaseapplock.
Eu escrevi um artigo confuso intitulado "Mutexes in SQL" aqui no SQL Server Central sobre como usar esses procedimentos armazenados para controlar o fluxo de aplicativos.