1. Introdução

A grande maioria das aplicações web precisa acessar um banco de dados . O Java EE requer servidores de aplicações para disponibilizar uma implementação DataSource(isto é, um pool de conexão para conexões JDBC) para esta finalidade.

O Tomcat oferece exatamente o mesmo apoio, de modo que os aplicativos baseados em banco de dados que você desenvolve utilizando este serviço será executado de modo inalterado em qualquer servidor Java EE.

Nota – O apoio da fonte de dados padrão no Tomcat é baseado no pool de conexão DBCP do projeto Commons. No entanto, é possível utilizar qualquer outro pool de conexão que implementa javax.sql.DataSource, escrevendo sua própria fábrica de recurso personalizado.

2. Instalar o driver JDBC

Os JAR(s) referente aos driver(s) necessário para a conexão com a base de dados, devem ser copiados para o diretório CATALINA_HOME/lib, o que torna os drive(s) disponíveis tanto para a fábrica de recursos quanto para sua aplicação.

Nota – Uma boa prática é copiar somente os JAR(s) que mais de uma aplicação utiliza em comun para o diretório CATALINA_HOME/lib, e os JAR(s) específicos de cada aplicação, em seu apropriado diretório de bibliotecas da própria aplicação.

3. Configurar a fábrica de recursos para um banco de dados

Para configurar uma fábrica de recursos no Tomcat, você deve editar o arquivo “CATALINA_HOME/conf/server.xml” adicionar um elemento como este abaixo para o elemento <GlobalNamingResources>.

<GlobalNamingResources>
	.....
	<Resource maxActive="10"
		  maxIdle="2"
		  maxWait="15000"
		  type="javax.sql.DataSource"
		  name="jdbc/MyDataSource"
		  username="myUsername"
		  password="myPassword"
		  driverClassName="oracle.jdbc.driver.OracleDriver"
		  url="jdbc:oracle:thin:@192.168.0.1:1521:orcl"/>

</GlobalNamingResources>

Detalhes das propriedades de configuração para recurso são as seguintes:

maxActive – Número máximo de conexões que podem ser alocados a partir deste conjunto ao mesmo tempo. Padrão: 8
maxIdle – Número máximo de conexões que podem permanecer inativas no pool de conexões ao mesmo tempo. Padrão: 8
maxWait – Número máximo de milissegundos que o pool vai esperar (quando não há conexões disponíveis) para criar uma nova conexão. Padrão: -1 (infinito)
type – Tipo do recurso
name – Nome para o JNDI, é este nome que utilizamos em nossas aplicações para se conectar a este recurso de dados.
username – Nome de usuário do banco de dados que será passado ​​para o driver JDBC.
password – Senha do banco de dados que também será passado ​​para o driver JDBC.
driverClassName – totalmente qualificado nome da classe Java do driver JDBC a ser utilizado.
url – URL de conexão para o banco de dados, que também será passado ​​para o driver JDBC.

Este DataSource exemplo que apresentei, esta configurado para acessar um banco de dados Oracle. Evidenciado fica, quando observadas as propriedades: “driverClassName” e “url” que são específicas para o banco oracle. Então para outros bancos de dado será necessário alterar as propriedades “driverClassName” e “url” com os valores específicos do banco que será utilizado.

4. Conclusão

Os benefícios encontrados ao utilizar um DataSource disponível no container ou servidor de aplicações são inúmeros, por exemplo:

  • Se alguém já pensou, implementou e testou um pool de conexões ágil o suficiente para gerenciar as conexões com o banco de dados, por que reinventar a roda ?! Se não precisar de algo muito específico que estes recursos não ofereçam, não vejo motivo para não usa-los.
  • Observo a estrutura em empresas seguindo o modelo: container/servidor de aplicações para ambiente de teste, homologação e produção. Em cada servidor um DataSource configurado para seu respectivo banco, porem todos os DataSources com o mesmo nome/JNDI. Assim a aplicação que usa este DataSource em desenvolvimento vai enxergar o banco de desenvolvimento, homologação o banco de homologação e o mesmo para produção. Com isso o desenvolvedor não precisa se preocupar em gerar uma versão para um ambiente específico somente porque utiliza diferentes bancos de dados.
  • Assim que criado o DataSource, ele fica disponível no namespace JNDI em todo o servidor, de modo que todas as aplicações tem acesso a ele. Seja por lookup explícito ou com a ajuda de CDI (Contexts and Dependency Injection).

A partir de agora você será capaz de criar e configurar um DataSource no Apache Tomcat.

Em uma próxima oportunidade, vou mostrar como configurar um DataSource em outros servidores de aplicações como o JBoss, Glassfish e Weblogic e também, como utiliza-los em uma aplicação JEE de diferentes maneiras.

Por enquanto é isso, até o próximo post.

3 comentários para “Criando um DataSource no Tomcat

  1. Rodrigo Almeida on 10 de janeiro de 2014 at 8:43 said:

    Belo post Ednei man.

    Cada vez aprendo mais com seus post.

    Haha, uma coisa é fazer a receita de bolo e a outra coisa é aprender.
    Abraço!

  2. Pingback: CDI – Injeção de recursos em Servlet | Parmigiani Júnior, Ednei

  3. marcelo on 1 de agosto de 2014 at 12:39 said:

    realmente muito bom. Nos precisamos de pessoas assim mesmo sempre dispostas a ajudar.

Deixe um comentário

Campos obrigatórios são marcados *

Post Navigation