Resiliência de conexão (JDBC)

Baixar o JDBC Driver

A resiliência de conexão permite que o driver JDBC restaure de forma transparente uma conexão ociosa interrompida e repita a conexão inicial se ela falhar. Este artigo aborda as duas propriedades de cadeia de conexão que controlam esse comportamento (connectRetryCount e connectRetryInterval) e as configurações keepalive que o driver usa para detectar uma conexão ociosa descartada. A resiliência de conexão está disponível a partir do Microsoft JDBC Driver 10.2.0 para SQL Server. Reconectar uma conexão idle quebrada requer o SQL Server 2014 e versões posteriores, ou Banco de Dados SQL do Azure.

Tip

A resiliência de conexão apenas tenta novamente a conexão inicial e restaura silenciosamente conexões ociosas interrompidas. Para tentar novamente automaticamente instruções que falharam (por exemplo, vítima do deadlock 1205 ou tempo limite de bloqueio 1222), ou para estender a lista de tentativas de nova conexão com números de erro personalizados (por exemplo, erros transitórios do SQL do Azure, como 40197 ou 40613), use a Lógica de repetição configurável. A CRL é baseada em regras; você escolhe os erros e o backoff, e ela funciona em conjunto com os recursos deste artigo.

Como o driver JDBC faz novas tentativas

O driver JDBC fornece três mecanismos de repetição independentes. Eles trabalham juntos, para que você possa usar todos eles de uma só vez:

Mecanismo O que faz Onde saber mais
Resiliência da conexão inativa Restaura de forma transparente uma conexão ociosa interrompida (por exemplo, uma conexão em pool fechada pelo servidor ou um balanceador de carga). Detectar conexões ociosas interrompidas (este artigo)
Tentativa de conexão inicial Repete a tentativa de uma conexão inicial com falha em intervalos fixos para uma lista predefinida de erros transitórios. Repetir conexões iniciais (este artigo)
CRL (lógica de repetição configurável) Nova tentativa baseada em regras para instruções que falharam e para números de erro personalizados. Introduzido no Microsoft JDBC Driver 12.10. Lógica de repetição configurável

Repetir conexões iniciais

O driver JDBC inclui duas propriedades de conexão que controlam com que frequência e quanto tempo o driver aguarda antes de tentar novamente a conexão inicial. Adicione essas propriedades ao cadeia de conexão ou defina-as por meio de propriedades da fonte de dados.

Palavra-chave Valores Padrão Descrição
connectRetryCount Um inteiro entre 0 e 255 (inclusive) 1 O número máximo de tentativas de estabelecer ou restabelecer uma conexão antes de desistir. Por padrão, o driver faz uma única nova tentativa. Um valor de 0 desabilita nova tentativa.
connectRetryInterval Um inteiro entre 1 e 60 (inclusive) 10 O tempo em segundos entre cada tentativa de conexão. O driver tenta se reconectar imediatamente quando detecta uma conexão ociosa interrompida e então aguarda connectRetryInterval segundos antes de tentar novamente. Essa propriedade é ignorada quando connectRetryCount é 0.

O motorista executa a primeira tentativa imediatamente e espera connectRetryInterval segundos antes de cada uma depois, então connectRetryCount as tentativas duram cerca (connectRetryCount - 1) * connectRetryInterval de segundos. loginTimeout delimita toda a sequência: o driver deixa de tentar novamente quando o tempo decorrido mais connectRetryInterval atinge loginTimeout, o que acontece um intervalo antes do próprio loginTimeout.

Essas propriedades repetem apenas a lista interna de erros transitórios de conexão. Para obter a lista completa de erros abordados (4060, 40197, 40501, 40613, 49918-49920 e outros), consulte a lista de erros de conexão transitória interna. Para adicionar números de erro personalizados a esse conjunto ou substituí-lo inteiramente, use retryConn na lógica de repetição configurável. Para repetir instruções com falha, use retryExec no mesmo artigo.

Caution

Se você definir retryConn sem um início +, ele substitui a lista embutida em vez de estendê-la. Qualquer erro interno que você mesmo não listar, incluindo o 40613, não será mais repetido.

Definir as propriedades

Definir connectRetryCount e connectRetryInterval na URL JDBC, em um Properties objeto ou em um SQLServerDataSource.

Na URL JDBC:

jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10

Com um objeto Properties. Neste artigo, os trechos de código Java omitem importações e declarações de classe para fins de brevidade.

Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("connectRetryCount", "3");
props.setProperty("connectRetryInterval", "10");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);

Com SQLServerDataSource:

SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setUser("...");
ds.setPassword("...");
ds.setConnectRetryCount(3);
ds.setConnectRetryInterval(10);

Conecte-se a um banco de dados serverless com pausa automática

Quando você usa o Banco de Dados SQL do Azure serverless com a pausa automática ativada, o banco de dados retoma na primeira tentativa de conexão. Essa tentativa falha com o erro 40613 enquanto a retomada é executada. Os bancos de dados geralmente retomam em menos de um minuto. Para mais informações, consulte Pausa automática e retomada automática.

O erro 40613 está na lista de erros de conexão transitória embutida, então o driver tenta a conexão novamente. Sua aplicação não precisa de uma lógica própria de repetição de tentativas para esse caso. As configurações padrão não contemplam uma retomada: connectRetryCount é 1, e o driver executa essa única nova tentativa imediatamente. Ambas as tentativas acontecem enquanto o banco de dados ainda está sendo retomado, então a aplicação detecta o erro.

Para tratar uma retomada, coloque as três propriedades juntas:

Property Por que isso importa
connectRetryCount Define quantas novas tentativas você terá. Configure-o para um valor acima do padrão de 1.
connectRetryInterval Define o intervalo entre as novas tentativas. A primeira tentativa é imediata; o driver espera esse tempo antes de cada nova tentativa subsequente.
loginTimeout Limita toda a sequência. O motorista para de tentar novamente assim que o tempo decorrido plus connectRetryInterval atinge loginTimeout.

Os seguintes valores são repetidos por cerca de um minuto, o que cobre uma retomada típica:

jdbc:sqlserver://<server>.database.windows.net;databaseName=<database>;encrypt=true;loginTimeout=120;connectRetryCount=5;connectRetryInterval=15

Aumentar loginTimeout por si só não ajuda, porque a tentativa de conexão falha rapidamente com 40613 em vez de ficar travada. Elevar connectRetryCount por si só também não ajuda, porque loginTimeout encurta a sequência.

Detectar conexões inativas interrompidas

Uma conexão ociosa típica é aquela que fica em um pool de conexões. O driver considera uma conexão ociosa após cerca de 30 segundos sem atividade. O servidor ou um dispositivo de rede entre o cliente e o servidor pode fechar conexões ociosas, portanto, o driver precisa de uma maneira de observar que o soquete está morto antes que a próxima consulta seja executada.

Para detectar conexões ociosas interrompidas, o driver depende dos pacotes keep alive TCP no nível do soquete. No Linux com Java 11 e versões posteriores, o driver habilita automaticamente pacotes keepalive em intervalos de 30 segundos (KeepAliveTime), com um atraso de 1 segundo entre as tentativas quando ocorre uma falha (KeepAliveInterval).

Importante

No Windows e no Java 11 ou anterior, você deve configurar os keepalives manualmente no sistema operacional para aproveitar a recuperação de conexão ociosa interrompida. Para obter informações sobre como configurar keep alives, confira Conexão com o banco de dados SQL do Azure.

Limitações

O driver não pode restaurar uma conexão ociosa interrompida quando qualquer uma das seguintes condições for verdadeira:

  • Há um conjunto de resultados aberto que não foi totalmente processado nem armazenado em buffer.
  • A conexão alternou os bancos de dados no SQL do Azure.
  • Há uma transação aberta.

Conteúdo relacionado

  • Last updated on