Pool de conexões, ou connection pooling, é uma técnica utilizada para otimizar o uso dos recursos associados a uma conexão de banco de dados. Nesta técnica, o servidor de aplicações gerencia uma coleção de conexões de banco de dados para servir os diversos usuários de um sistema. O uso do pool de conexões tem dois objetivos principais. O primeiro é escalabilidade, uma vez que permite o compartilhamento de um número menor de conexões físicas para atender às requisições de conexões de uma aplicação. Esse compartilhamento é possível com o uso do tempo ocioso de uma conexão para atender outras requisições da aplicação. Desta forma, temos um relacionamento 1:N, onde uma conexão física pode atender N conexões lógicas.
O segundo objetivo é performance, já que minimiza o elevado custo para se estabelecer conexões com o banco de dados. Esse elevado custo é referente à necessidade de alocação memória, criação de um processo servidor e uma série de recursos necessários para o estabelecimento de uma conexão com o banco de dados. O pool de conexões minimiza esse custo ao manter, sempre, conexões pré-estabelecidas, sem que seja necessário abrir e fechar, repetidamente, as conexões físicas com banco de dados.
Por outro lado, o aspecto negativo do uso de pool de conexões para o banco de dados é que, como todas as conexões são feitas utilizando um mesmo usuário de banco de dados, cujo nível de privilégios é normalmente alto, o banco de dados e/ou DBA não tem conhecimento de qual usuário da aplicação está usando, efetivamente, cada sessão. Dessa forma, a monitoração e auditoria das atividades da aplicação, utilizando os recursos do banco de dados podem ficar comprometidas (podem por que existe um mecanismo que utilizamos para lidar com esta limitação). Além dos aspectos de segurança, monitoração e auditoria, vale lembrar ainda que, com freqüência, é necessário re-implementar funcionalidades que o Oracle já oferece, o que representa um custo desnecessário.
O Oracle oferece duas alternativas que permitem resolver o problema e responder à pergunta da Figura 1. Utilizando o parâmetro de contexto da sessão CLIENT_IDENTIFIER ou utilizando autenticação através de PROXY USERS. Assim, a aplicação pode informar à camada de banco de dados qual usuário está, de fato, utilizando cada conexão física no banco de dados. Dessa forma, é possível utilizar os recursos de segurança, auditoria e monitoração do banco de dados, sem a necessidade de abrir mão dos benefícios do pool de conexões.
Client_identifier
Nesse método, ao solicitar uma conexão ao pool de conexões, a aplicação deve atribuir à variável de contexto da sessão CLIENT_IDENTIFIER o identificador do usuário da aplicação, o que permite a identificação do usuário da aplicação enquanto ele estiver utilizando a conexão. Não se pode esquecer que, antes de devolver a conexão ao pool de conexões, a aplicação deve limpar essa informação, para informar que a conexão não está mais sendo utilizada.
A utilização desse método é aconselhável nos casos onde a aplicação já foi desenvolvida utilizando pool de conexões com um único usuário de banco de dados ou quando a aplicação tem muitos usuários e não se quer manter, no banco de dados, cada usuário real da aplicação.
A package (pacote) pré-defenida DBMS_SESSION é utilizada, neste método, para manipular a variável CLIENT_IDENTIFIER ...
