A JTA é a espeficação do mundo JAVA EE responsável por definir a API necessária para controlarmos
transações dentro das nossas aplicações. Como controle transacional é uma característica que está
presente em quase todo projeto, acabamos usando essa especificação tanto em containers JAVA EE,
como um Wildfly, quanto em Servlet Containers, como um Tomcat ou Undertow.
Não se assuste: apesar de possuir diversas opções e funcionamento, no dia a dia utilizamos funcionalidades mais que não são nada complicadas
Autor(a)
Alberto Souza
Alberto é desenvolvedor e coordenador dos treinamentos da Caelum São Paulo. Ele investe parte do seu tempo livre para criação de projetos pessoais, como o SetupMyProject.com, e colabora com projetos open source, como o VRaptor e o Stella.
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Utilização da JTA dentro um servidor de aplicação
Quando optamos por rodar nosso código dentro de um servidor de aplicação, ganhamos de brinde as implementações
de todas as especificações que compõe o JAVA EE, entre elas a JTA. Para tentar facilitar o entendimento,
vamos supor que temos um projeto simples para fazer um cadastro de livros.
Uma funcionalidade bem simples é a adição de livros. Para não termos que falar de parâmetros nem nada,
vou apenas deixar um método responsável por criar dois livros.
Agora, caso eu acesse o endereço configurado, recebo a seguinte exception:
org.jboss.resteasy.spi.UnhandledException: javax.persistence.TransactionRequiredException: WFLYJPA0060:
Transaction is required to perform thisoperation(either use a transaction or
extended persistence context)
O Wildfly está dizendo que uma transação é necessária para conseguirmos salvar nosso livro no banco de dados.
Container Managed Transactions
Para resolver este problema, basta que façamos a seguinte alteração:
@Transactionalpublic String criaVariosProdutos() {
manager.persist(newProduto("jaxrs-project"));
manager.persist(newProduto("spring-project"));
return manager.createQuery("select p from Produto p").getResultList().size() + "foram criados";
}
Perceba que adicionamos a annotation Transactional em cima do nosso método. Apenas com essa alteração
ensinamos ao servidor de aplicação que nosso método deve ser executado dentro de uma transação.
Esse nível de facilidade só existe por conta do CDI. Essa especificação é responsável por definir
o comportamento de um container de injeção de dependências no mundo JAVA EE e representa a cola que
faltava entre todas as especificações. Desde o JAVA EE 6, existe um trabalho para que todos os objetos
sejam criados como beans do CDI. Dessa forma ficou mais fácil realizar integrações entre as especificações.
Por exemplo, para que seja possível o funcionamento da annotation Transactional, é criado um interceptor
que controla o fluxo da transação. Está descrito no javadoc da annotation. Abaixo segue um trecho:
This support is provided via an implementation of CDI interceptors that conduct the
necessary suspending, resuming, etc. The Transactional interceptor interposes on business method
invocations only and not on lifecycle events. Lifecycle methods are invoked in an unspecified
transaction context.
Caso você queira, ainda pode definir o detalhe de como a transação deve ser gerenciada. Para isso é necessário que
seja passado o argumento informando o tipo de transação. Abaixo temos a lista de possibilidades.
REQUIRED Caso não exista uma transação, ela é iniciada. Caso alguam outra já esteja sendo executada, nada é feito. Este é o tipo mais comumente usado.
REQUIRES_NEW Uma nova transação sempre vai ser criada. Caso alguma já esteja em andamento, a atual é suspensa e uma nova transação é executada.
MANDATORY Informa que uma transação é obrigatória para determinado momento.
SUPPORTS Informa que o método pode rodar com ou sem uma transação ativa.
NOT_SUPPORTED Informa que a transação corrente deve ser suspensa para a execuçao de determinado método. Quando o método acaba, a transação volta a ficar ativa.
NEVER Informa que tal método nunca deve rodar em um contexto transacional.
Situação especical caso a sua classe seja marcada como EJB
Caso a sua classe também seja marcada com a annotation Stateless ou Stateful, ela vai ser tratada pelo servidor de aplicação como um EJB. E aí, por default, todo método de um EJB que faz uso de um recurso transacional já é executado sob o contexto da JTA automaticamente. Não existe a necessidade de declarar a annotation Transactional.
Política de rollback
Uma parte também importante de entendermos é como funciona o mecanismo de rollback da JTA. Vamos imaginar um cenário
onde precisamos aceitar um pedido de compra de um livro na loja. Um detalhe importante é que nossa API precisa
avisar a quem está chamando o código que existe a possibilidade daquele pedido não ser processado naquele
momento por falta de estoque. Uma possibilidade de código poderia ser a que segue:
Nós sempre queremos salvar o pedido, afinal de contas podemos fazer alguma coisa com essa informação.
A pergunta que fica é: será que ele foi salvo mesmo? Afinal de contas lançamos uma exception aqui.
Para responder o questionamento é necessário saber se SemEstoqueException é uma exception checada.
Caso ela seja filha direta de Exception, ou seja, checada, o interceptor do CDI que é responsável
por controlar a transação vai entender que essa exception não deve gerar um rollback na aplicação. O JAVA EE entende que uma exception checada tem a ver com o negócio. Tanto que elas são chamadas de ApplicationException. Agora, caso ela seja uma exception não checada, filha de RuntimeException, o comportamento padrão do interceptor vai ser marcar a transação para rollback. Esse último tipo de exception, é entendida pelo JAVA EE como uma SystemException. Literalmente um problema não esperado(bug) e, por conta disso, a transação não deve ser efetivada.
Uma segunda opção relativa ao comportamento de rollback em função das exceptions é a utilização do
parâmetro rollbackOn ou do dontRollbackOn. Ambos recebem um array de exception. Para não ter que ficar lidando com exceptions checadas, você pode assumir a criação apenas de filhas de RuntimeException. No momento que você entender que um rollback não precisa ser feito, basta usar o parâmetro dontRollbackOn.
Não faz sentido para o exemplo usar o rollbackOn porque o comportamento da exception não checada já é de rollback por default. Você poderia usá-la para forçar o rollback numa exception checada.
Bean Manager Transactions
Em geral, o recomenado é utilizar o controle transacional provido pelo container e não ficar implementando este código de infraestrutura. Entretanto, as vezes necessitamos de um controle mais
fino. Por exemplo controlando o tempo de execução máxima da transação. Para este tipo de cenário,
podemos deixar claro que queremos o controle do fluxo.
A annotation TransactionManagament deve ser usada quando você quer trocar o comportamento do controle transacional para manual. O default é o gerenciamento feito via container. Isso está explícito
no código fonte da própria annotation.
Perceba que conseguirmos pedir injetado o objeto do tipo UserTransaction, que é responsável por fazer o controle transacional manual. Com esse objeto em mãos, apenas iniciamos e comitamos uma transação no ponto que queremos. Esse código de controle transacional solta diversas exceptions checadas, para facilitar o entendimento omitimos elas e adicionamos um throws para Exception.
Caso alguma coisas desse errado, poderíamos informar que precisamos de um rollback.
userTransaction.rollback();
Inclusive, agora se for necessário que essa operação execute em um limite de tempo estabelecido, podemos usar o método setTransactionTimeout que recebe um int com o número de segundos máximo.
Como foi dito no começo da seção, a melhor maneira é deixar este tipo de tratamento para o container. Só use se realmente você tiver com uma necessidade especial.
Se você esitver rodando uma aplicação baseada no Spring e configurada com o Spring Boot, executar um código envolvido num contexto transacional é muito simples. Veja abaixo o exemplo:
Perceba que usamos a mesma annotation Transactional da especificação JTA. Isso só é possível porque
as annotations de todas as especificações são semânticas. Elas não falam nada sobre detalhes de implementação,
apenas declaram o que precisa acontecer naquele ponto do código. Dessa forma qualquer projeto pode tirar
proveito das mesmas annotations.
Dentro de um servidor de aplicação
Caso o Spring tenha sido executado dentro um servidor de aplicação, ele automaticamente vai
procurar pela implementação disponível da específicação através da JNDI. Você pode olhar um pouco
sobre ele como faz isso acessendo o código fonte
da classe JTATransactionManager.
Fora do servidor de aplicação
Por outro lado, se o Spring tiver sido executado isoladamente, por exemplo através de uma aplicação
com Spring Boot e um servlet container embedado, ele não vai ter disponível uma implementação da JTA
para se basear. Geralmente, mesmo nesse contexto, o projeto usa a JPA e para essa situação o Spring conta
com sua própria implementação de contexto transacional baseada na JPA. Você pode acessar o código fonte
seguindo este link.
A especifição JTA é amplamente usada em todos os nossos projetos. Seja através de uma implementação completa e integrada em um servidor de aplicação, seja através das suas annotations que podem ser lidas por qualquer outro projeto.
