Post on 19-May-2015
description
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