Transações em EJB

Introdução aIntrodução aTransações em EJBTransações em EJB

Natanael FonsecaArquiteto JEE

TransaçõesTransações

Definição:◦Unidade atômica de trabalho◦Pode ser formada por várias operações chamadas a

partir de vários objetosO padrão EJB suporta transações distribuídas

◦Entre vários application servers e vários bancos de dados

As transações são realizadas em nível de beans e não em nível de tabelas de bancos de dados

| 2

Comandos de transaçõesComandos de transações

BEGIN◦Inicia uma nova transação

COMMIT◦Confirma as operações/mudanças realizadas na

transaçãoROLLBACK

◦Desfaz as operações/mudanças realizadas na transação

| 3

Participantes de transaçõesParticipantes de transaçõesRecursos com estado transacional

◦Exemplo: Conexão de banco de dadosResource Manager

◦Exemplo: Driver JDBC 2.0Servidor de aplicaçõesGerenciador de transações

◦Controla o estado da transação◦Controla todos os resource managers

envolvidos em uma transação

| 4

Contexto transacionalContexto transacionalUm contexto transacional:

◦Representa a transação compartilhada pelos objetos transacionais participantes

◦É propagado automaticamente para objetos transacionais na medida em que são usados

◦Permite a sincronização dos objetos transacionais envolvidos no momento de commit ou rollback

| 5

Transações DistribuídasTransações Distribuídas

Uma transação distribuída é associada a um thread.

A transação fica ativa enquanto o thread realiza chamadas a objetos, possivelmente em vários servidores

O contexto transacional é propagado pelo container, para cada chamada de método

O padrão EJB obriga que a propagação de transações seja transparente para o bean (propagação implícita)

Transações distribuídas são suportadas por two-phase commits

| 6

Transações DistribuídasTransações Distribuídas

Atualizações em Atualizações em múltiplos bancos múltiplos bancos de dadosde dados

| 7

• Atualizações em Atualizações em múltiplos bancos de múltiplos bancos de dados através de dados através de vários application vários application serversservers

Demarcação de transaçõesDemarcação de transaçõesA demarcação de transações envolve

◦O início de uma transação◦A confirmação (commit) de uma transação ◦O cancelamento (rollback) de uma transação

Dois tipos de demarcação de transações◦Container-managed transaction demarcation (CMT)

◦Bean-managed transaction demarcation (BMT)

| 9

Demarcação implícita x explícitaDemarcação implícita x explícita

| 10

Cliente EJB

método de negócio

Cada método é uma transação (implícito)

Implícito, usando

especificação declarativa

Demarcação explícita

(pelo cliente)

Cliente EJB

método de negócio

O cliente determina os limites da transação

UserTransaction

begin()

commit()

Demarcação BMTDemarcação BMT

Apenas session beans podem usar BMTO bean possui controle total sobre a

transaçãoÉ necessário usar javax.transaction.UserTransaction

O tipo de demarcação de transações (CMT ou BMT) é indicado no deployment descriptor

| 11

Demarcação de transações BMTDemarcação de transações BMT

| 12

Cliente EJB

método de negócio

O Session Bean determina os limites da transação

UserTransaction

begin()

commit()

Session Bean

método de negócio

Demarcação gerenciada pelo

bean

Demarcação CMTDemarcação CMT

A declaração do uso de CMT é feita no Deployment Descriptor

Quando CMT é declarado, fica proibido o uso de outro tipo de demarcação de transações

É proibido o controle de transações usando:◦java.sql.Connection◦javax.transaction.UserTransaction

| 13

Container-managed transactionsContainer-managed transactions

Com CMT, o container gerencia as transações de forma transparente

CMT pode ser usado para session beans e entity beans

O bean não tem acesso às transações◦Qualquer tentativa de controlar transações

explicitamente causa uma exceção

| 14

Container-managed transactionsContainer-managed transactions

Deve ser indicado no Deployment Descriptor o tipo de gerenciamento de transações CMT

São especificados atributos de transações (transaction attributes) para cada método

| 15

Atributos de transaçãoAtributos de transação

Atributos de transações definem os requisitos transacionais para o método

Seis tipos de atributos◦Required◦RequiresNew◦Supports◦NotSupported◦Mandatory◦Never

| 16

Atributos RequiredAtributos Required Usa a transação existenteUsa a transação existente

Se não houver transação, inicia nova transação; termina a Se não houver transação, inicia nova transação; termina a nova transação no final de sua execuçãonova transação no final de sua execução

| 17

ClienteCliente ContainerContainer BeanBeanT1T1 T1T1 T1T1

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma T1T1 T1T1

Atributos Atributos RequiresNewRequiresNew Sempre inicia uma nova transação; encerra a transação Sempre inicia uma nova transação; encerra a transação

ao finalao final

| 18

ClienteCliente ContainerContainer BeanBeanT1T1 T2T2 T2T2

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma T1T1 T1T1

Atributo Atributo SupportsSupports Não inicia uma nova transaçãoNão inicia uma nova transação

A associação transacional existente não é suspensaA associação transacional existente não é suspensa

| 19

ClienteCliente ContainerContainer BeanBeanT1T1

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma NenhumaNenhuma NenhumaNenhuma

T1T1 T1T1

Atributo Atributo NotSupportedNotSupported Não inicia uma nova transaçãoNão inicia uma nova transação

A associação transacional existente é suspensaA associação transacional existente é suspensa

| 20

ClienteCliente ContainerContainer BeanBeanT1T1

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma NenhumaNenhuma NenhumaNenhuma

NenhumaNenhuma NenhumaNenhuma

Atributo Atributo MandatoryMandatory Deve ser chamado de dentro de uma transação; caso Deve ser chamado de dentro de uma transação; caso

contrário levanta exceçãocontrário levanta exceção

| 21

ClienteCliente ContainerContainer BeanBeanT1T1 T1T1 T1T1

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma

TransactionTransactionRequiredExceptionRequiredException

Atributo Atributo NeverNever

Chamar um método desse tipo com uma transação em Chamar um método desse tipo com uma transação em andamento gera uma exceçãoandamento gera uma exceção

| 22

ClienteCliente ContainerContainer BeanBeanT1T1

ClienteCliente ContainerContainer BeanBeanNenhumaNenhuma NenhumaNenhuma NenhumaNenhuma

RemoteExceptionRemoteException

Transações CMTTransações CMT

A demarcação de transação pode ser feita através de Anotations (EJB3);

| 23

Transações CMTTransações CMTA demarcação de transação também

pode ser feita através do arquivo ejb-jar.xml (EJB2);

| 24

Rollback CMTRollback CMTDa mesma forma que o commit o

comando rollback é chamado automaticamente;

É executado quando uma exceção do tipo SystemException é levantada;◦Herdadas de RuntimeException;

Exceções de aplicação (Checked) não causam o rollback na transação;◦Herdadas de Exception

| 25

Rollback OnlyRollback Only

Para que as exceções de aplicação causem o rollback é necessário que o programador identifique a mesma e chame manualmente o método setRollbackOnly();

O bean usa esses métodos para marcar uma transação para rollback, ou para obter informações sobre o estado de uma transação, não para controlar a transação

| 26

......

@Resource SessionContext ctx;

Public void inserirPaciente(Paciente p) throws Public void inserirPaciente(Paciente p) throws

PacienteJaExistenteExceptionPacienteJaExistenteException {{

...//<...//<regras de negócio>regras de negócio>}catch(}catch(PacienteJaExistenteExceptionPacienteJaExistenteException ex) ex) { { ejbContext.ejbContext.setRollbackOnly()setRollbackOnly();; throw ex;throw ex;}}

Rollback CMTRollback CMTDesta forma, o programador deve tomar

cuidado com as exceções de aplicação;◦Ele deve manualmente dar rollback utilizando

EJBContext,◦Ou marcar que essas exceções causem rollback

automaticamente via annotation;O exemplo anterior a exceção

PacienteJaExixtenteException realiza herança da classe Exception;◦Capturamos a exceção, realizamos os rollback e

relançamos a exceção;

| 27

Package br.fucapi.controlemedico;Package br.fucapi.controlemedico;

@ApplicationException(rollback=true)@ApplicationException(rollback=true) ;Public class PacienteJaExistenteException extends Exception {Public class PacienteJaExistenteException extends Exception {

public void PacienteJaExistenteException(String pNomePac){public void PacienteJaExistenteException(String pNomePac){......

}}}}

Rollback OnlyRollback Only

| 28

Marcamos a classe PacienteJaExistenteException com a annotation @ApplicationException;O container EJB irá dar rollback automaticamente quando esta exceção for levantada dentro de um método de negócio;

Transações e Usuário FinalTransações e Usuário FinalO conceito de transação para o Usuário

Final (UF) é um pouco diferente do de banco de dados;

A visão de transação para o UF está ligado as operações que ele realiza na interface gráfica;

Um conjunto de passos em uma interface gráfica é encarada como apenas uma transação para o UF◦Esta pode representar mais de uma transação

de BD;

| 29

Transações e Ambientes Multi-Transações e Ambientes Multi-usuáriosusuários

As transações de banco de dado devem ocorrer em um curto espaço de tempo dentro dos métodos de negócio;

O acesso concorrente em um registro de tabela está protegido por uma transação apenas dentro dos métodos de negócio com demarcação;

| 30

Transações e Ambientes Multi-Transações e Ambientes Multi-usuáriosusuários O tempo de uma transação para o usuário segue os seguintes passos:

◦ Inicia no momento que o mesmo avistou a informação na UI, ◦ passando pelo momento de confirmação da operação (através de um

botão, Link etc) ◦ e finalizando com a tela de sucesso;

O tempo decorrido é bem maior;

| 31

Visãoda informação

ProcessamentoEJB Tela sucesso

Transação de BD

Transação para o Usuário

Transações e Ambientes Multi-Transações e Ambientes Multi-usuários WEBusuários WEB

O acesso/modificação concorrente ao informação por mais de um usuário põe em risco a integridade do BD;

| 32

Edição PessoaCod 143

ProcessamentoEJB Tela sucesso

T1 (1-10 seg)

Usuário A

T1 (11-12 seg)

Edição PessoaCod 143

ProcessamentoEJB Tela sucesso

T1 (1-5 seg)

Usuário B

T1 (06-07 seg)

Transações Long RunningTransações Long Running

Damos o nome de long running transactions (LRT) as transações que demoram mais que o normal para completar a operação completa;

Devemos evitar as LRTs:◦Consomem muitos recursos computacionais;◦Podem gerar dead locks;◦Podem segurar recursos por muito tempo

deixando as aplicações lentas;Devemos transformá-las em transações menores

quando possível;

| 33

Transações Long RunningTransações Long Running

Não existem tempo ideal de timout para transações de um sistema;◦O arquiteto deve observar a aplicação e verificar a

média de tempo de uma transação que depende da aplicação, do hardware, da memória e da rede disponíveis;

As LRTs podem ser limitadas na configuração do driver JDBC;

Uma transação que não oferece problemas hoje, pode a vir se tornar uma LRT amanhã;

| 34