Migrando do InterBase para o Firebird 1.5 no - Guj

sistemas legados e banco de dados e também no padrão JDBC. O padrão JCA especifica uma arquitetura
onde um servidor de aplicação pode cooperar com um driver de tal forma que este gerencie transações,
segurança, pool de conexões e outros recursos e o driver provê apenas a funcionalidade de conexão.
O novo JayBird 1.5 traz algumas melhorias e inovações:
• Além da implementação do tipo JDBC 4, este driver implementa também o tipo 2 e uma versão
embedded server, a qual permite criar aplicações com todos os requisitos para conexão a um
servidor embutida na própria aplicação.
• Suporte para IN e OUT stored procedures. O JayBird 1.0 provia suporte apenas a parâmetros IN
enquanto esta nova versão implementa todos os requisitos também a parâmetros OUT.
• Nova infraestrutura para pool de conexões e prepared statements.
O tipo JDBC 4 é uma implementação totalmente em Java que converte chamadas JDBC diretamente para
o protocolo utilizado pelo banco de dados. Esta difere da implementação de tipo 3, que converte uma
chamada para um protocolo independente que depois é convertida, por um servidor intermediário, para o
protocolo específico do banco em questão. Enquanto o tipo 4 é preferido para configurações onde o
cliente localiza-se numa máquina diferente da do servidor, sua performance é prejudicada quando as
conexões são feitas ao servidor Firebird a partir da mesma máquina onde este se encontra. Isto deve-se
ao fato que o tipo JDBC 4 utiliza sockets para realizar conexões, introduzindo um overhead adicional.
Quando a comunicação com o servidor de banco de dados será efetuada a partir da mesma máquina
onde este está instalado, como pode ser o caso de aplicações web em Java onde o container web roda na
mesma máquina do banco de dados, é preferível utilizar o tipo JDBC 2. Este, utiliza uma biblioteca nativa
JNI para efetuar as conexões, possibilitando uma performance superior pois acessa o banco de dados
diretamente.
Um pool de conexões provê um meio de gerenciar e manipular conexões a bancos de dados. Sua
principal utilidade é minimizar o tempo necessário para uma aplicação obter uma conexão a um banco,
tendo em vista que, em geral, esta é uma operação que consome considerável tempo. Além disso, outras
vantagens são:
• Gerenciamento do número limite de conexões. Uma aplicação não pode abrir mais conexões do
que o permitido pelo pool.
• Centralização do lugar onde conexões a bancos de dados serão obtidas.
• Possibilidade também de fazer pool de prepared statements.
Um prepared statement é uma instrução SQL compilada e otimizada apenas uma vez para ser utilizada
várias vezes por uma aplicação, reduzindo assim o tempo de execução quando esta se encontra, por
exemplo, num loop. Porém, o que acontece quando precisamos utilizá-la durante o ciclo de vida de um
objeto? Devemos criar uma conexão dedicada ao objeto, já que um prepared statement é
intrinsecamente relacionado à conexão que o criou, ou preparar um cada vez que for necessário utilizálo?
As duas opções são insatisfatórias, a primeira por ser inviável no sentido de consumir uma conexão
para cada objeto instanciado que faz uso de prepared statement e a segunda por perder a principal
vantagem que é a possibilidade de reutilização de consultas já compiladas e otimizadas.
Um pool de prepared statements resolve estes problemas. Veja o exemplo abaixo:
Connection connection = dataSource.getConnection(); 1
try { 2
PreparedStatement ps = connection.prepareStatement( 3
“SELECT * FROM test_table WHERE id = ?”); 4
try { 5
ps.setInt(1, id); 6
ResultSet rs = ps.executeQuery(); 7
while (rs.next()) { 8
// faz alguma coisa 9
} 10
} finally { 11
ps.close(); 12
} 13
} finally { 14
connection.close(); 15
} 16
As linhas 1 a 16 apresentam um código típico quando um pool de prepared statements está sendo
utilizado. A aplicação obtém uma conexão através de um javax.sql.DataSource, prepara uma consulta
Grupo de Usuários Java – http://www.guj.com.br – Página 4