Esse artigo faz parte da revista Clube Delphi Edição 87. Clique aqui para ler todos os artigos desta edição

0pt; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none; TEXT-ALIGN: left; mso-padding-alt: 1.0pt 4.0pt 1.0pt 4.0pt; mso-border-alt: solid windowtext .5pt" align=left>Para acessar o Firebird no ASP.NET, você pode utilizar o provider ADO.NET do próprio Firebird. Para baixá-lo, utilize o seguinte endereço: www.firebirdsql.org/index.php?op=files&id=netprovider. A versão utilizada é para o .NET Framework 1.1. A instalação é bastante simples, basta executar o instalador.

Para instalar no Delphi 2006, acesse o menu Component>Installed Components. No editor, digite “Firebird” em Category, clique no botão Select an Assembly e escolha o arquivo FirebirdSql.Data.Firebird.dll, que por padrão encontra-se  em: C:\Arquivos de programas\FirebirdNETProvider1.7. Clique em OK e veja na Tool Palette os componentes instalados para acesso ao Firebird.

 

Connection Pooling

Inicie uma nova aplicação ASP.NET no Delphi 2006. A partir da Component Palette, coloque um FbConnection no Web Form. Selecione o componente e no Object Inspector acesse o editor da propriedade ConnectionString. No editor que aparece informe os parâmetros para acesso ao banco Employee.fdb do Firebird.

Com isso, configuramos a conexão ao Firebird usando o provider nativo, a primeira dica de performance (jamais use OleDB,  ODBC ou outro provider nesse caso).

 

Figura 1. Parâmetros de conexão ao Firebird

 

Observe que em User Name e Password informamos um usuário e senha padrão para acesso ao banco. Aqui vai a segunda dica valiosa para otimização: forneça um usuário e senha fixos, de forma que todos os usuários que conectem à aplicação utilizem as mesmas credenciais.

Se for necessário restringir acesso a determinado usuário, defina isso na forma de autorizações no Web.config. Fornecer um usuário fixo fará o ADO.NET utilizar de forma efetiva o recurso de Connection Pooling, sem ter perda de desempenho.

Connection Pooling é o mecanismo que permite ao ADO.NET reaproveitar conexões ao banco de dados. Imagine a seguinte situação: um usuário acessa a aplicação, conectamos ao BD para extrair informações e a exibimos no formulário. A seguir, fechamos a conexão e devolvemos o resultado ao browser.

Como aplicações Web são state less (sem estado), se esse mesmo ou outro usuário se conectar à aplicação, uma nova conexão precisará ser restabelecida. Conectar ao BD a cada requisição de usuário é literalmente um suicídio em ambiente Web, onde uma aplicação pode ter centenas e até milhares de conexões simultâneas.

O ADO.NET resolve isso de forma bastante elegante: após a página ser enviada ao browser, a conexão com o BD não é liberada, mesmo que você tenha chamado explicitamente o método Close do FbConnection. O ADO.NET guarda automaticamente a conexão em pool (imagine isso como uma espécie de cache de conexões).

Ou seja, a conexão fica aberta com o banco de dados e persiste entre requisições. Quando outro usuário conectar na aplicação, o ADO.NET verifica se existe uma conexão disponível no pool e caso encontre, a utiliza. Com isso, todo o tempo necessário para localizar o servidor de BD, estabelecer uma conexão, autenticar um usuário e verificar permissões não será mais consumido a cada requisição.

E o melhor de tudo, você não precisa fazer nada para usar esse recurso, pois ele já é ativado por padrão. Criar um mecanismo de Connection Pooling “no braço” via código é algo extremamente complicado (infelizmente já tive que passar por esse esforço em uma ocasião). No ADO.NET já temos isso pronto no próprio framework. Produtividade é um dos pontos fortes do .NET.

 

...

Quer ler esse conteúdo completo? Tenha acesso completo