You are currently browsing the archives for the java category


Message-Driven Beans e Transações

Sexta-feira passada, postei  em meu twitter que estou tocando um projeto que envolve MOM. Hammm… JMS, para ser mais específico… rsrsrs…. Bem, o fato é que este projeto acabou me motivando a escrever este post sobre o assunto transação e EJB3 Message-Driven Beans (MDB),  apenas para fazer alguns lembretes e dar algumas dicas, já que este é um assunto fundamentalmente importante. Vamu que vamu então…

A primeira coisa importante a saber é que transações não são propagadas do produtor de mensagens JMS para o MDB que as consome, independentemente destes trabalharem com CMT ou BMT. Isso se dá pela própria natureza assíncrona de um sistema baseado em MOM, uma vez que uma mensagem pode levar horas para ser consumida, se assim fizer sentido ao sistema. Assim sendo, uma transação de um MDB está limitada ao escopo do método onMessage, que recebe e trata as mensagens.

A segunda coisa importante a saber é que quando o MDB faz o seu próprio gerenciamento de sua transação, a mensagem consumida não é parte transação. Ao passo que, se a transação do MDB for gerenciada pelo contêiner EJB, sim, a mensagem é parte da transação.

Sabendo essas duas coisas, somos levados a uma questão: O que acontece entãos se a transação falhar? Bem, está é a terceira coisa importante que precisamos saber. Sempre que o método onMessage completa sua execução sem erros, o contêiner EJB notifica ao provedor JMS reconhecendo o recebimento da mensagem. No entanto, se o correr uma RuntimeException durante a sua execução, o provedor JMS não receberá esta notificação de reconhecimento e, muito provavelmente, disponibilizará a mensagem para ser novamente consumida pelo MDB. Isso poderia causar um problema sério de loop infinito, em caso de poison messages, mas felizmente há antidoto para isso: Configurar o número máximo de tentativas de entrega de mensagens. Uff!!!

Como lidar então com exceções, rollback e reentrega de mensagens?

Há momentos em que a reentrega de mensagens é fundamental; e há momentos que não. Se ocorrer uma exceção de negócio, por exemplo, você não vai querer que a mensagem seja entregue novamente. Mas, se ocorrer um exceção por indisponibilidade de uma recurso (banco de dados, web service, etc), seria fundamental que a mensagem fosse entregue novamente, depois de algum tempo. Com isso em mente, vamos discutir um pouquinho o assunto.

Primeiro de tudo, não se esqueça que MDB’s não retornam exceções ao cliente que produziu a mensagem. Se a sua lógica de negócio em cima da mensagem produzida pelo cliente prevê uma exceção, pare e pense um pouco a respeito. Se você puder responder a ele com uma outra mensagem que ele (ou outro MDB responsável por notificar clientes) poderá consumir no provedor JMS, ótimo; caso contrario, esqueça, mensagens assíncronas não é uma opção para você.

Seguindo adiante com a solução, você precisa saber como MDB’s CMT ou BMT se comportam quando o assunto é transação. As diferenças básicas entre esses dois modelos de gerenciamento de transações são as seguintes:

Se seu MDB está baseado em CMT, significa que as mensagens que ele consume são parte da transação. Portanto, se a transação sofrer rollback, automaticamente, o consumo da mensagem também será revertido e o provedor JMS deverá tentar entregar a mensagem novamente.

Já, se seu MDB está baseado em BMT, significa que se a transação sofrer rollback o consumo da mensagem não será revertido, como acontece automaticamente no caso de CMT, e você poderá manter isso em segredo do provedor JMS, evitando que ele entregue a mensagem novamente. Ou, se fizer sentido ao seu requisito, você poderá notificá-lo do rollback de maneira bem simple e segura, basta lançar uma EJBException que é pá/pum.

Um pouco mais sobre Reconhecimento de Mensagem

A propriedade acknowlodgeMode, que determina o modo de reconhecimento da mensagem, pode ser definida como Auto-acknowledge ou Dups-ok-acknowledge. A primeria opção, instrui o contêiner EJB a notificar o reconhecimento da mensagem dentro do contexto da transação, seguindo as regras já citadas; e a segunda, o instrui a fazer isso num outro momento qualquer.

Essa propriedade pode ser ignorada, a menos que você esteja implementando um BMT ou um CMT com atributo de transação definido como NotSupported. Do contrario, o reconhecimento sempre ocontecerá no contexto da transação.

Se quiser saber mais, indico que você leia esse material.

Resumindo: Tome cuidado com suas exceções e não deixe que elas explodam sem mais nem menos, sem um tratamento adequado, nem nada, porque elas podem detonar suas transações e ainda causar problemas de negócio, com a reentrega de mensagens. Um bom log também vai muito bem, meu caro! :)

Bom, é isso ai… Espero que te ajude!

E se você ainda não leu esses dois posts: Cuidado com suas exceções e Transacionando EJB3 Session Beans, quando tiver um tempinho, leia. Talvez lhe sejam úteis também.

Até a próxima!

Web services RESTful em Java com Jersey

Estou estudando hoje a JSR 311 e sua implementação de referência, o projeto Jersey, por conta de um requisito arquitetural que surgiu em meu novo projeto aqui na CVC Turismo. Trata-se da integração de várias aplicações legadas, desenvolvidas com tecnologias completamente heterogêneas – Java, ASP e PL/SQL Web Toolkit.

Estamos, eu e meus colegas da equipe de arquitetura, considerando bastante o uso de web services REST. Por isso meu interesse pelo Jersey, uma vez que a plataforma base desse projeto é Java.

Para aqueles que se interessam pelo assunto, tempos atrás gastei investi um tempo lendo o material produzido pelo Bruno Pereira, o qual considero a melhor referência de REST em lingua portuguesa. (Jabá!!!)

Hoje resolvi ler também um de seus artigos produzidos para a revista Java Magazine – que IMHO não é lá uma ótima revista de Java, mas que volta e meia publica um ou dois artigos interessantes -, para refrescar a memória.

Taí! Para quem quer ter um primeiro contato com Jersey e a JSR 311, ficam aqui as dicas.

Acho que Ola Bini não dorme!

Ola Bini publicou hoje em seu blog um roadmap para sua mais nova criação, a linguagem de programação Ioke.

Ioke é, nas palavras do próprio Ola Bini, uma lingagem de programação fortemente tipada, orientada a objetos baseada em protótipos, bastante inspirada em Io, SmallTalk, Self, Ruby e Lisp (especialmente Common Lisp). Atualmente, ela está implementada em Java e rodar unicamente na JVM.

Nesse roadmap, Ola Bini anuncia que a primeira release será chamada 0 (sim, zero), e deverá ser publicada até no máximo o Natal.

Se você quiser acompanhar a evolução de Ioke, você pode segui-la no GitHub.

Agora fica a pergunta: Esse Ola Bini não dorme, não?

Django agora compatível com Jython

Saiu do forno a versão 1.0 do Django e trouxe consigo uma boa notícia: Foram removidas todas as incompatibilidades com Jython, o interpretador Python 100% implementado em Java, para rodar Python na Java Virtual Machine.

Porém, isso só é verdade para  Jython 2.5, que ainda não está disponível para produção. Na verdade, o time de desenvolvimento ainda está para lançar uma versão alpha (2.5a1).

Quen, quen, quen, quennnnnn…

Mais diversão com Scala

Uma das coisas que mais tenho estudado ultimamente é a integração entre linguagens de programação – principalmente com Java -, de maneira a extrair o melhor de cada uma delas, o mais transparentemente possível. Scala, tal como JRuby, tem me proporcionado isso de maneira fantástica.

Scala tem total integração com Java, uma de suas plataforma host (a outra é o Microsoft .Net Framework). Assim, pode-se usar classes e interfaces de bibliotecas Java de forma natural. Vejamos um exemplo bem simples:


import java.util.{Date, Locale}
import java.text.SimpleDateFormat

object ExibeDataFormatada {
  def main(args: Array[String]) {
    val now = new Date
    val formatter = new SimpleDateFormat(
      "EEEE, dd 'de' MMMM 'de' yyyy")

    // método com apenas um parâmetro podem ser invocados
    // com sintaxe infix
    println(formatter format now)
  }
}

Este código, certamente, é bem familiar para qualquer programador Java. O que ele faz é:

1. Importar as classes Date e Locale do pacote java.util, bem como a classe SimpleDateFormat do pacote java.text;
2. Criar um objeto ExibeDataFormatada, que é um pequeno aplicativo Scala, e definir um método main, dentro do qual o aplicativo executará;
3. Criar dois val‘s (valores imutáveis): now para a data atual do sistema, e formatter para formatar nossa data atual;
4. Invocar o método format do objeto formatter, passando-lhe como parâmetro now, que é a data atual.

(Se quiser rodar esse código, veja este post.)

Você deve ter notado que Scala trabalha com classes Java de maneira totalmente natural. Na verdade, muitas classes Scala fazem wrap de classes Java e as melhoram – como as classes com prefixo Rich.

Este foi um exemplo muito simples mesmo, mas creio que já deu para você ver que coisas muito sofisticadas também podem ser feitas com a mesma naturalidade.

Acredito que a integração entre linhagens é o que pode alavancar muitos projetos de requisitos complexos e totalmente heterogêneos. Porque sempre há algo que se pode fazer melhor e mais barato em uma linguagem do que em outra. Só é preciso tomar cuidado para não acabar criando uma Torre de Babel.

E você, o que pensa disso?

Que tal um pouco de script na plataforma Java?

Diego Carrion postou em seu blog um artigo muito legal sobre o uso de linguagens de script na plataforma Java, a ilustre JSR-233.

Vale a pena conferir!

Um pouco de diversão com Scala

Scala é uma linguagem de programação muito flexivel, que possibilita conceber construções extremamente sofisticadas, o que facilita bastante a criação de DSLs. Ela combina dois poderosos paradigmas: Programação Orientada a Objetos e Programação Funcional. Tudo em Scala é um objeto, inclusive, funções. Ela não é a única que faz isso, mas vem ganhando aplausos pelo seu design sofisticado. Na verdade, Scala foi inspirada em muitas linguagens – Java, C++, Smalltalk, Eiffel, OCaml, F#, Haskell, Erlang.

Scala também possui um ótimo modelo de programação concorrente, inspirado nos poderosos atores de Erlang.

Não bastasse tudo isso, Scala é open source e possui implementações para a plataforma Java e .NET.

Uma das coisas que mais gosto em Scala é sua natureza funcional. Não que eu seja um mestre da programação funcional. Mas este é um paradigma que tenho aprendido a apreciar bastante.

Sobre esse extenso assunto, quero fazer uma pequenina citação a “funções”.

Uma função em Scala é um first-class value. Como qualquer outro valor, uma função pode ser passada por parâmetro para outra função, bem como ser retornada como resultado. Funções que recebem outras funções como parâmetro ou retornam como resultado são chamadas de higher-order function. Isso dá um flexibilidade impressionante!

Um exemplo?

object Calculo {
  def soma(func: Int => Int, a: Int, b: Int): Int =
    if (a == 0 || b == 0) func(10) else a + b

  def main(args: Array[String]) {
    println("Ex1: " + soma((x: Int) => x + 100, 0, 0))
    println("Ex2: " + soma((x: Int) => x + 100, 10, 20))
  }
}

Este é um programinha bastante simples. O que ele faz é criar um objeto Calculo, que funciona como uma instância singleton, e executá-o a partir do método main – semelhantemente ao que acontece em Java.

Além do método main, lá está nossa função soma. Ela é uma função simples de soma. Bem, não tão simples assim. Ela recebe uma função anonima por parâmetro (func) e, caso a ou b seja zero, ela a usa passando 10 como parâmetro.

Se quiser rodar este programinha e ver o resultado de sua execução, basta:

1- Instalar a versão de Scala para seu SO;
2- Salvar esse código em um arquivo Calculo.scala;
3- Compilar esse arquivo com scalac Calculo.scala;
4- Executar com scala Calculo.

Scala é uma linguagem fantástica. Quando mais a conheço, mais a aprecio!

Executar JRuby a partir do Java

Nos últimos tempos tenho dedicado boa parte do meu tempo livre estudando JRuby. Tem sido uma verdadeira diversão!

Com o objetivo de compartilhar um pouco do que tenho aprendido, eis aqui este post…

Quer dizer que o osrevni inverso também é verdade?

Muito se fala da capacidade do JRuby de acessar código Java de maneira tão natural quanto o faz com seu próprio código – o que é definitivamente fantástico. Mas não tenho visto muitos exemplos de código Java acessando código JRuby. Por quê? Não sei dizer. Talvez porque não tenham visto tanta utilidade nisso. Essa não é minha opinião, já que tenho interesse em implementar algumas coisas em JRuby e usar a partir do Java.

Uma das coisas que fiz nesses meus estudos sobre usar JRuby a partir de Java foi testar o compilador jrubyc para gerar .class, mas não cheguei bem onde eu queria – até troque umas palavras com Charles Nutter a respeito -, porque o .class gerado por ele não é do tipo que se pode instanciar e usar diretamente num código Java, dada a natureza totalmente dinâmica de Ruby. Nas palavras do próprio Charles:

The code compiled by jrubyc is not a “normal” Java class[…] This is not a Java class you can instantiate and call methods on directly from Java[…].

Como não desisti, tenho algumas alternativas para compartilhar.

OBS.: Para executar os exemplos apresentados é necessário ter jruby.jar no classpath do seu projeto. Quando escrevi este post estava usando a versão 1.0, porque não havia uma versão mais atual na máquina que eu estava usando. Mas agora já atualizei o código para a versão 1.1.3.

Primeira alternativa: JRuby puramente Ruby

No exemplo abaixo, criou uma classe Ruby comum – sem qualquer recurso específico do JRuby – e, logo após, a carrego, instancio e executo seu método a partir do Java.

matematica_apenas_ruby.rb

class MatematicaApenasRuby
  def soma(a, b)
    a + b
  end
end

MatematicaApenasRubyTest.java

public class MatematicaApenasRubyTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_apenas_ruby.rb", false);

        Object mat_ruby = rubyRuntime.evalScriptlet("MatematicaApenasRuby.new");
        Integer res_ruby = (Integer)JavaEmbedUtils.invokeMethod(rubyRuntime, mat_ruby, "soma", new Integer[] {3, 2}, Integer.class);

        System.out.println("Soma 3 + 2 invocando diretamente JRuby: " + res_ruby);
    }
}

O que esse código Java faz é bem simples, ele:

1- Inicializa um ambiente de runtime para Ruby, indicando onde estão os arquivos .rb;
2- Executa o script de criação da classe MatematicaApenasRuby;
3- Executa o script de instanciação da classe MatematicaApenasRuby;
4- E, por fim, invoca o método soma passando dois parametros.

Que tal, acho simples? Pois muito bem, continuemos…

Segunda alternativa: JRuby implementando Java

Neste segundo exemplo, o que eu faço é criar uma classe JRuby que estende uma classes Java abstrata, o que facilita ainda mais na hora de usar a partir do Java. Vejamos como fica.

matematica_impl_java.rb

require 'java'

class MatematicaImplJava < Java::IntegracaoPoliglota::Matematica
  def soma(a, b)
    a + b
  end
end

Matematica.java

package integracao.poliglota;

public abstract class Matematica {
    public abstract int soma(int a, int b);
}

MatematicaImplJavaTest.java

public class MatematicaImplJavaTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_impl_java.rb", false);

        Object mat_impl_java = rubyRuntime.evalScriptlet("MatematicaImplJava.new");
        Matematica matematica = (Matematica)JavaEmbedUtils.rubyToJava(rubyRuntime, (IRubyObject)mat_impl_java, Matematica.class);

        System.out.println("Soma 10 + 2 usando a interface Java: " + matematica.soma(10, 2));
    }
}

E esta alternativa, gostou? Eu gostei bastante. Porque no meu caso, o que eu quero é poder definir uma interface em Java e implementar com JRuby a la Ruby Way e depois usar no Java. É claro que não estou levando em conta o fator “performance”, só estou considerando o fator “alternativa de implemententação”. Só isso.

Mas vamos lá, o que esse código faz?

1- A classe JRuby estende uma classe Java abstrata, como dito antes;
2- A classe que faz o teste, em linhas gerais, faz um cast do objeto JRuby para a classe Java abstrata;
3- E no final das contas, invoca o método da classe Java.

Será que programação poliglota é o futuro?

Se é ou não é, eu não sei. Mas sei que deixei de ser um arquiteto de uma nota só há muito tempo; e estou muito emplogado com JRuby – ele é o melhor dos dois mundos!

E você, o que acha? Deixe um comentário…

Cuidado com suas exceções!

Um tema bastante trivial, mas não pouco importante, são as sempre presentes Exceções. Outro dia desses me deparei novamente com elas – em um dos projetos que presto consultoria [em arquitetura] – e resolvi escrever este post, como uma pequena “dica”, digamos assim, para quem ainda não está totalmente seguro com o tema. Por fim, ele também servirá como complemento ao meu post anterior que aborda o tema transações em EJB3 Session Beans.

Conceituando as coisas

Em Java há dois tipos de exceções:

– Checadas (checked),
– E não checadas (unchecked).

As exceções checadas são identificáveis em tempo de desenvolvimento e, obrigatoriamente, devem ser capturadas (try…catch) e tratadas – seja com uma mensagem “amigável” ao usuário, ou com um algoritmo alternativo, ou seja lá como for. Estas exceções são identificáveis em tempo de desenvolvimento, por isso, são muito uteis na hora de sinalizar que uma “regra de negócio” foi violada – também conhecidas como exceção de aplicação – e, portanto, algo deve ser feito.

Alguns exemplos deste tipo de exceção seriam:

– MaioridadeNaoIdentificavelException
– ValorPagamentoMenorTaxaEmbarqueException
– DataReservaInvalidaException

Já as exceções não checadas normalmente não são identificáveis em tempo de desenvolvimento, por isso são conhecidas como exceções de runtime – e não coincidentemente, são filhas de RuntimeException. Estas exceções geralmente (mas não invariavelmente) denotam erros de sistema que não são recuperáveis.

Exemplos destas exceções na própria API do Java são:

SecurityException
NullPointerException
MissingResourceException

E, como uma prática comum, também é bom notar que exceções não checadas não são declaradas na clausura throws dos métodos os quais podem lançá-las.

Tomando decisões

Quando você entende este conceito fica simples saber quando usar uma ou outra, não? Sim. Quer dizer, sim, mas também, não! Mas por que não? Hammm… Veja só…

IllegalArgumentException denota que um parâmetro inválido foi passado a um método, correto? Sim, é isto que diz a documentação. Bem, neste caso, imagine que você estivesse escrevendo um método de negócio, e neste método você tivesse que consistir os seus parâmetros. Imaginou? Tá. Agora, o que você faria se um dos parâmetros fosse invalido?

a) Lançaria uma IllegalArgumentException
b) Criaria uma exceção própria [checada] para denotar parâmetros inválidos

Sem pensar muito, você ficaria tentado a optar por (a), certo? Creio que sim. Mas esta não seria uma boa opção, se estes parâmetros forem realmente essenciais para o dado método; e se for possível para o código que executa este método tomar uma “decisão de negócio”, se souber que um ou mais parâmetros são inválidos. Neste caso, o melhor é a opção (b). É preciso ficar atento para escolher a melhor opção em cada situação.

Um pouco sobre exceções em EJB3

Todos os métodos de um EJB3 Session Bean lançam uma exceção do tipo EJBException, que é não checada, caso algo de errado aconteça. Isto automaticamente desencadeia um processo de rollback na transação atual, e grava um registro de log no application server para conhecimento do administrador do sistema.

Como fica então se quisermos lançar nossas próprias exceções? É muito simples, mas é também preciso se ater a um detalhe:

“Se a exceção que você lançar for não checada, ela será automaticamente encapsulada por uma EJBException, o que torna o tratamento desta exceção nada fluente na aplicação cliente, uma vez que não será pego de maneira ‘especifica’ pela seu bloco catch. Isto quer dizer que você somente conseguirá capturar uma EJBException, e não uma NaoConseguiEnviarEmailException, por exemplo.”

No caso deste meu cliente, que usa Oracle Application Server, a EJBException encapsula uma OracleRemoteException, que por sua vez encapsulada a exceção que de fato foi lançada. Que beleza, né? Beleza nada, uma praga! rsrsrs

Então, cuidado! Se você estiver trabalhando com EJB3 e quiser lançar uma exceção não checada, não se esqueça que o cliente de seu EJB não saberá (de forma natural, com um simples try…catch) que exceção realmente foi lançada.

Aqui permanece então o que foi dito acima:

– Exceção de negócio, prefira que seja checada,
– E de sistema, prefira que seja não checada, caso realmente não possa trata-la.

Talvez agora você esteja se perguntando: Mas e a transação, como fica? Ela será abortada quando uma exceção checada for lançada?

A resposta é… Não, ela não será abortada. Porque nem sempre uma exceção de negócio requer um rollback de transação. Aliás, também não será registrado qualquer log no application server – porque erros de negócio são irrelevantes a administradores de sistema.

Mas nem tudo esta perdido. EJB3 provê uma anotação para possibilitar que você aborte uma transação caso uma dada exceção checada ocorra.

@javax.ejb.ApplicationException tem um atributo rollback que pode ser definido como true ou false, indicando que a transação deve ser abortada ou não. Assim, basta fazer esta anotação em sua exceção e pronto!

Essa é uma maneira fácil de garantir a atomicidade de sua transação, porque caso ocorra alguma exceção de negócio que de fato viole o acordo da transação, automaticamente, a transação será abortada.

Bom, é isso… Chega de exceções por hoje!

Transacionando EJB3 Session Beans

Um dos requisitos mais importantes em aplicações de software que lidam com modificações de dados persistentes é o controle transacional. O que significa que não podemos simplismente ignorá-lo. Por isso, resolvi escrever este post.

Antes de mais nada, que raios é uma transação?

Uma transação, em linhas gerais, do ponto de vista de negócio, denota uma troca entre duas partes. Por exemplo, numa compra online de livro, você troca uma certa quantia em dinheiro debitada de seu cartão de crédito, por um livro de sua escolha. Ao participar de uma transação de negócio como esta, você procura se certificar de que o valor debitado em seu cartão de crédito é de fato o valor da compra. Caso contrario, há a possibilidade de você estar sendo enganado sem nem mesmo tomar conhecimento – o que não é nada divertido.

Ótimo. Mas onde isso impacta nossos softwares?

Em termos de software, um bom design de seus objetos de negócio não garante que tudo estará bem ao final de um transação. Uma pena. Mas o problema não está no objeto de negócio por si só, ou mesmo no seu processo de negócio. O buraco ainda é um pouquinho mais embaixo.

Em uma aplicação de software, uma transação é bem semelhante ao conceito “toma lá, dá cá” que acabei de apresentar acima, recheado de atividades inter-relacionadas que devem ser completadas em conjunto. A este conjunto de atividades dá-se o nome de unidade de trabalho. (Martin Fowler inclusive catalogou em seu livro Patterns of Enterprise Application Architecture um design pattern que reside nesse campo de transação de negócio chamado Unit Of Work.) Assim, o objetivo final de um transação é executar uma unidade de trabalho, de ponta a ponta, resultando em uma troca 100% confiável. Afinal, ninguém quer comprar gato por lebre, não é mesmo?

Sabendo disso, como podemos garantir esta confiabilidade?

Aqui entra o tal ACID

Quatro características são fundamentais em transações para estas sejam seguras.

1- Atômica, porque uma transação deve executar completamente ou definitivamente não executar. Isso significa que cada trarefa em uma unidade de trabalho deve executar sem qualquer erro, pois se algum erro ocorrer, a transação deve ser abortada e todas alterações revertidas para o estado anterior ao início da transação.

2- Consitente, já que ninguém gostaria de pagar R$ 50,00 no cartão de crédito e, por fim, ao receber a fatura de cobrança, ver que está sendo cobrado R$ 500,00 – e não R$ 50,00. Essa é uma responsabilidade que cabe ao desenvolvedor, que deve consistir cada dado antes de persisti-lo, e ainda, garantir que as tabelas (em caso de banco de dados) estejam preparadas para receber os tais dados.

3- Isolada, porque não é conveniente que os dados estão sendo manipulados por uma transação sejam ao mesmo tempo modificados por outra unidade de trabalho. Imagine que desagradável seria acontecer isso no momento de finalizar uma compra on-line, por exemplo.

4- Durável, uma vez que os dados precisam ser armazenados fisicamente em algum local enquanto a transação está acontecendo, para que não se percam caso o sistema trave.

Daí o acrônimo ACID.

Finalmente, como EJB3 nos permite controlar transações?

EJB3 dá-nos uma maneira muito simples de controlar transações em Session Beans através de uma simples anotação: @javax.ejb.TransactionAttribute.

Você pode aplicar essa anotação tanto em métodos individualmente, quanto na própria classe do bean – o que torna abrangente a todos os métodos. Ou mesmo, se for o caso, você pode aplicar na classe do bean e em seus métodos individualmente, ao mesmo tempo – neste caso, a anotação do método sobrepõem-se à da classe do bean.

@javax.ejb.TransactionAttribute recebe como atributo uma enum TransactionalAttributeType, que tem as seguintes opções:

MANDATORY, define que o método do bean deve ser parte do escopo de transação do cliente, pois o bean pode não iniciar sua própria transação. Caso o cliente não tenha uma transação iniciada, uma falha ocorrerá e será lançada uma exceção javax.ejb.EJBTransactionRequiredException.

REQUIRED, significando que o método do bean deve ser invocado no escopo de uma transação. Caso o cliente não houver chamado este método como parte de uma transação, uma nova transação será iniciada. Mas será encerrada ao final da executação deste método.

REQUIRES_NEW, significa que sempre uma nova transação é iniciada, independente do cliente ter feito a invocação do método do bean em um escopo de transação ou não. O que acontece é que a transação do cliente é suspensa até que o método do bean retorne; e a nova transação, obviamente, só é válida durante a execução do método do bean.

SUPPORTS, indica que o método do bean pode ser invocado dentro de um escopo de transação ou não. Ele pode, inclusive, interagir com outros beans que não estão inseridos em um escopo de transação.

NOT_SUPPORTED, suspende a transação até que o método do bean termine a sua execução. Isso faz com que a transação não seja propagada a qualquer outro método de bean que este invoque.

NEVER, define que um método do bean não pode jamais ser invocado em um escopo de transação. Caso isso aconteça, uma exceção javax.ejb.EJBException será lançada.

Conclusão

Esse modelo de controle transacional é bastante simples de se aplicar, mas ao mesmo tempo poderoso. Como ele fica muito fácil definir as unidades de trabalho – ou, escopos de transação – e garantir as características ACID em sua aplicação de software.

Mas se você não usa EJB3, tudo bem também, não há problema, fico te devendo um post sobre controle transacional com Spring Framework. =)

Até a próxima!