Lucas Teixeira

Quem enviou foi o Felipe Juliani.

Neste caso, devemos usar ao invés das conexões declaradas no DataSource.groovy, uma declaração de conexão com banco de dados via JNDI.

JNDI é uma árvore de ‘nomes’ que referenciam ‘recursos externos’. O que isso quer dizer? Basicamente, que a sua aplicação poderá pegar uma configuração de fora da aplicação, diretamente de um “lugar” na JVM que alguém colocou. Seria mais ou menos um clipboard compartilhado, só que de objetos é claro :)

Então para o caso acima, nada melhor que deixar toda essa ‘configuração’ de conexão com o banco de dados do lado de fora da aplicação e fazer com que ela vá buscar apenas pelo ‘nome’ desta conexão. Pronto, desta maneira a configuração fica externa a nossa aplicação e feita diretamente no nosso container.

Bom, eu particularmente vejo três grandes razões para o uso de DataSources JNDI. A primeira é quando devemos tirar do desenvolvedor a (ir)responsabilidadade de dimensionar/configurar a utilização de banco de dados. Isso é um trabalho de infra estrutura, e se em algum determinado momento infra estrutura resolver aumentar o pool de conexões de banco da aplicação, consegue fazer isto sem encostar na aplicação, diretamente no container onde ela está rodando.

Outro motivo é a melhor utilização de recursos de banco de dados. Vamos imaginar um cluster de servidores de aplicação com 3 nós. Cada um dos nós roda uma instância da sua aplicação, que está configurada (diretamente no DataSources.groovy) com um pool de 10 conexões, ou seja, só de subir as aplicações, você terá 30 conexões com o banco já feitas. Com DataSources neste caso, todas as instâncias da aplicação poderiam ir buscar conexões com o banco de dados no mesmo DataSource, configurado uma única vez. Com isso, não precisamos necessariamente possuir 30 conexões abertas com o banco, pois quando uma instância necessita de todas elas, outra instância pode estar usando apenas 3 ou 4.  É claro que para isso, além dos servidores e da aplicação, o seu DataSource também precisa estar deployado no cluster todo.

E o terceiro motivo, é o apontado pelo Felipe acima, que precisa deixar uma maneira fácil de trocar o banco de dados da aplicação. Com estes DataSources JNDI fica fácil também, já que a url do banco, driver, e credenciais estão do lado de fora, na configuração do DataSource.

E para criar este DataSource?

Bom, o primeiro passo é levantar em que container você está rodando a sua aplicação, pois cada um tem a sua maneira particular de configuração, seja jetty, tomcat, jboss ou weblogic. Além das diferenças durante a criação do DataSource, temos também diferenças na ‘formação’ do nome deles. No caso do weblogic por exemplo, o mais simplista neste quesito, você poderia ter um datasource com o nome de “PedidosDS”, já no JBoss, ele fica prefixado desta maneira: “java:<nome_datasource>”.

E depois disso, na configuração da sua aplicação Grails, na closure do environment específico que você quer, basta descrevê-lo desta maneira:

production {
   dataSource {
      jndiName = "<nome_datasource>"
   }
}

Vale lembrar que estes dias postei sobre como criar um datasource no jboss e usá-lo em uma aplicação grails. Não deixe de ler também.