Considerações sobre a reutilização de uma sessão ou conexão entre vários threads¶

Efeitos da reutilização de uma sessão ou conexão em vários threads¶

Os usuários de drivers geralmente criam aplicativos com vários threads. Em vez de criar sessões e conexões separadas para cada thread, você pode tentar economizar algum overhead reutilizando uma sessão ou conexão em diferentes threads. Você deve estar ciente de que isso pode causar os seguintes comportamentos indesejáveis:

• Estado da sessão

  As sessões mantêm o controle do banco de dados, do esquema e da função atuais. Se um thread alterar esses valores (como USE DATABASE), o outro thread poderá ser afetado. Esse impacto é especialmente importante porque a mudança para outro esquema com as mesmas tabelas pode fazer com que um thread modifique acidentalmente a tabela errada. Além disso, a alteração dos parâmetros de conexão ou configuração em uma sessão pode afetar todos os threads que usam essa sessão.

• Estado da transação

  Uma transação pode começar em uma sessão. Se vários threads tiverem acesso a essa sessão, cada um deles poderá modificar os dados na mesma transação, o que pode fazer com que os dados sejam acidentalmente persistidos ou perdidos se uma transação for confirmada ou revertida.

• Contador de sequências

  Os drivers usam um contador de sequência para tentar novamente as solicitações. Como os contadores de sequência são globais para uma sessão, a reutilização de uma sessão em diferentes threads também pode alterar inadvertidamente o contador de sequência global, o que pode resultar em um comportamento imprevisível para a repetição de solicitações.

• Cache de contexto de consulta

  Para melhorar o desempenho, as sessões mantêm o controle de algumas informações internas em um cache interno ou específico do driver. O cache é atualizado após cada consulta, portanto, a execução de várias consultas ao mesmo tempo em uma sessão pode resultar em corrupção de dados.

• Último ID de consulta

  As conexões mantêm o registro do último ID de consulta, que pode ser recuperada e usada. Se duas consultas forem executadas em paralelo em diferentes threads, uma condição de corrida pode afetar qual delas define o último ID de consulta.

Recomendações Snowflake¶

• Use pools de conexão sempre que possível.

  Se você reutilizar conexões entre threads para evitar a autenticação frequente, deve considerar o uso de pools de conexão. O uso de pools de conexão diminui o número de solicitações de autenticação, pois a sessão não é encerrada no final - ela apenas é devolvida a um pool, onde fica pronta para ser usada na próxima ocasião. Mesmo ao usar pools de conexão, seu aplicativo deve ter cuidado para não alterar ou redefinir parâmetros que afetem apenas uma consulta específica ou um banco de dados atual. Além disso, o aplicativo é responsável por confirmar ou abortar as transações ativas antes de retornar uma conexão ao pool de conexões.

• Use as consultas assíncronas com cautela.

  Iniciar várias consultas assíncronas ao mesmo tempo em uma única conexão, ou iniciar uma consulta síncrona enquanto uma consulta assíncrona ainda está em andamento, pode resultar em uma condição de corrida que pode causar resultados imprevisíveis.

• Use otimizações adicionais de autenticação.

  Drivers específicos oferecem suporte a algumas ou todas as otimizações a seguir, que você pode usar para melhorar o desempenho da autenticação:

  • Caches de tokens de SSO

  • Caches de tokens de MFA

  • Tokens nos arquivos de configuração do TOML

  • Acessores de token personalizados

  Você deve verificar a documentação do driver para ver quais dessas opções são compatíveis com o driver.

• Desativar o cache de contexto de consulta.

  Se você estiver ciente de todos os problemas associados à reutilização de sessões e conexões em vários threads, mas ainda quiser usá-las, o Snowflake recomenda que desative o cache de consulta configurando o parâmetro DisableQueryContextCache como false na definição da conexão.