Daniel Tamiosso

Introdução

Seguindo com a série de posts sobre EJB, vamos explanar e entender o suporte que ele proporciona no gerenciamento de transações. Primeiramente, precisamos entender o conceito de transação.

Na vida real realizamos diversas transações diariamente: desde bancárias até mesmo amorosas. Por exemplo, você só leva pra casa a camisa do maior time do Brasil (para os menos informados, falo do glorioso Internacional), se a operadora do seu cartão de crédito autorizar a compra. Caso contrário, a camisa fica lá iluminando a vitrina da loja. Assim, também, podemos relacionar os casos amorosos. Neles precisamos seguir uma cartilha de regras (para os homens: lêia-se o complicado mundo das mulheres) a nós impostas, para podermos levar a um final feliz (ou pelo menos uma tentativa disso) a relação. Caso contrário…

Então uma transação é tudo aquilo que envolve uma série de ações onde o seu desfecho final depende do sucesso dessas ações para poder acontecer (committed). Caso contrário todas essas ações são desfeitas imediatamente (rolled back).

No nosso incrível mundo de desenvolvimento de sistemas, as transações funcionam seguindo
essa mesma linha de raciocínio. Nele as transações são contempladas por quatro características, denominadas pelo acronômo ACID (Atomicidade, Consistência, Isolação e Durabilidade).

Propriedades ACID

• Atomicidade: transações são atômicas desde sempre. Isso quer dizer que: ou tudo é executado com sucesso, ou seu estado original é retomado.
• Consistência: somos os responsáveis diretos por cuidarmos dessa propriedade. Por isso é a mais delicada desse grupo. Está diretamente ligada a forma como escrevemos o código. O sistema de informação deverá estar consistente com seus dados e regras de negócios ao término da transação se o mesmo a iniciou assim. Embora durante uma transação o sistema não necessita estar consistente com essas informações.
  
• Isolação: todas as mudanças que são realizadas durante uma transação podem ser isoladas, isto é, tornadas imperceptiveis para outras transações até que a a mesma seja finalizada. Isso ocorre em sincronização de threads e “locking” em um banco de dados. Essa característica é muito importante para ambientes onde existem muitos processos concorrentes.
• Durabilidade: uma vez uma transação finalizada com sucesso (commited), seus dados devem estar devidamente armazenadas e não podendo ser desfeitas. Ou seja, uma vez confirmada a transação, temos que garantir que seu resultado é “durável”.

Gerenciamento de transações

As transações quando são responsáveis por gerenciar somente um recurso, é uma transação local. Entretanto, na experiência do dia-a-dia sabemos que isso não é algo tão comum. O momento é todo das aplicações distribuídas. E apenas um recurso de armazenamento de dados, muitas vezes, não é o suficiente. Por isso existe o transaction manager, que é o responsável por abstrair toda essa complexidade para nós. É ele que coloca todos esses recursos dentro de uma única transação.

Para que isso possa ocorrer com sucesso ele usufrui do chamado Two-Phase-Commit, que consiste basicamente em dividir a fase de commit de uma transação em dois passos. Primeiramente verifica se existe a possibilidade de commit em todos os recursos envolvidos. Caso sim, deixa todos eles em estado commitment (compromisso). E só após todos estarem “compromissados” com a transação é que realmente ela será commited.

O protocolo mais utilizado e recomendado para coordenar o Two-Phase-Commit é o Protocolo XA. Ele é o responsável por fazer com que os recursos envolvidos e o transactional manager falem a mesma língua tornando assim viável essa comunicação.

Todo o suporte que EJB dá a transações é fornecido através da JTA (Java Transaction API). É ela que expõe as funcionalidades que são distribuidas na camada de gerenciamento de transações pelo servidor de aplicação. Com isso temos duas saídas básicas para gerenciarmos nossas transações:

• Container-Managed Transactions (CMT): pode ser configurada com anotações ou com um descriptor. Elas iniciam antes da chamada de um método de negócio de um EJB e dependendo dos acontecimentos na execução desse método a transação é rollback ou commited. Elas podem ser classificadas em:

1. Requerid (requerida): onde o container cria uma transação ou, se houver uma transação no método que chamante, cria uma junção (continuação), dessa transação.
2. Requires new (requer nova): onde o container cria uma transação ou, se houver uma transação no método que chamante, suspende esta transação e cria uma nova transação.
3. Supports (apoia): onde o container não cria uma transação se não houver no método chamante, ou se houver realiza uma junção (continuação), dessa transação.
4. Mandatory (obrigatória): sempre precisará de uma transação anterior para poder realizar uma junção com ela. Caso contrário lançara uma exceção.
5. Not suported (não suportada) : Se não houver transação anterior, aqui continua sem também. Se houver, ela é suspensa e o método continua sem controle de transação.
6. Never (nunca): Se não houver transação anterior, aqui continua sem também. Se houver, é lançada uma exceção.

• Bean-Managed Transactions (BMT): requer uma configuração programática onde devemos mostrar onde teremos uma transação e onde ela poderá realizar um roll back através da chamada da interface javax.transaction.UserTransaction.

Bom, isso foi só algumas referências básicas sobre o funcionamento das transações com o uso de EJB. Com o tempo quero aprofundar o artigo aqui no blog.

Muito obrigado pela leitura.

Abraços a todos.

Popularity: 31% [?]

• Deixe um comentário