Transações em EJB
Upcoming SlideShare
Loading in...5
×
 

Transações em EJB

on

  • 2,621 views

Apresentação sobre transações em EJB

Apresentação sobre transações em EJB

Statistics

Views

Total Views
2,621
Views on SlideShare
2,619
Embed Views
2

Actions

Likes
4
Downloads
36
Comments
2

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Qual o significado de sincronização?
  • Two-phase commit Two-phase commit is a protocol complying to the XA interface. It ensures that the result of a transaction is consistent across all resource managers participating in the transaction. It is used only in distributed transactions. The protocol operates in distinct phases to ultimately commit or abort a transaction. Phase one evaluates the status of each resource manager. The transaction manager checks with each local resource manager, whether they are ready to commit the transaction. Each resource manager responds that they are ready or not. A transaction can commit only when all participating resource managers agree during this phase one. This phase is called the prepare phase. Phase two concludes the transaction. Based on the response from each resource manager, the transaction manager instructs all resource managers to commit the transaction if all agree or to roll back the transaction if at least one disagrees. This phase is called commit phase.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.
  • Foi tirado pelo motivo de pouco tempo para ministrar as aulas. Este assunto foi considerado irrelevante, pois iremos focar na aula prática. Se o mesmo for utiliszado no futuro é bom dar uma olhada no wikpedia que contem vários exemplos sobre o assunto TRANSACTION_READ_UNCOMMITTED Dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row. TRANSACTION_READ_COMMITTED Dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it. TRANSACTION_REPEATABLE_READ Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read"). TRANSACTION_SERIALIZABLE Dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.

Transações em EJB Transações em EJB Presentation Transcript

  • Introdução aTransações em EJB Natanael Fonseca Arquiteto JEE
  • Transações Definição: ◦ Unidade atômica de trabalho ◦ Pode ser formada por várias operações chamadas a partir de vários objetos O 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ções BEGIN ◦ Inicia uma nova transação COMMIT ◦ Confirma as operações/mudanças realizadas na transação ROLLBACK ◦ Desfaz as operações/mudanças realizadas na transação | 3
  • Participantes de transações Recursos com estado transacional ◦ Exemplo: Conexão de banco de dados Resource Manager ◦ Exemplo: Driver JDBC 2.0 Servidor de aplicações Gerenciador de transações ◦ Controla o estado da transação ◦ Controla todos os resource managers envolvidos em uma transação | 4
  • Contexto transacional Um 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í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ídas  Atualizações em múltiplos bancos de dados • Atualizações em múltiplos bancos de dados através de vários application servers | 7
  • Níveis de isolamento Níveis de isolamento determinam o nível de acesso a um objeto envolvido em uma transação por um thread em outra transação Cada resource manager pode usar níveis de isolamento diferentes Todos os acessos dentro de uma transação são feitos com os mesmos níveis de isolamento Conflitos em níveis de isolamento devem ser evitados quando múltiplos EJBs fazem acesso ao mesmo resource manager | 8
  • Demarcação de transações A 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ícita Cliente EJB Implícito, método de negócio usando especificaçã o declarativa Cada método é uma transação (implícito) User Cliente Transaction EJB begin() método de negócio commit() Demarcação explícita (pelo cliente) O cliente determina os limites da transação | 10
  • Demarcação BMT Apenas session beans podem usar BMT O 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 BMT User Cliente Session Bean Transaction EJB método de negócio begin() método de negócio Demarcação commit() gerenciada pelo bean O Session Bean determina os limites da transação | 12
  • Demarcaçã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 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 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çã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 Required  Usa a transação existente  Se não houver transação, inicia nova transação; termina a nova transação no final de sua execuçãoCliente T1 Container T1 Bean T1Cliente Nenhuma Container T1 Bean T1 | 17
  • Atributos RequiresNew Sempre inicia uma nova transação; encerra a transação ao finalCliente T1 Container T2 Bean T2Cliente Nenhuma Container T1 Bean T1 | 18
  • Atributo Supports  Não inicia uma nova transação  A associação transacional existente não é suspensaCliente T1 Container T1 Bean T1Cliente Nenhuma Container Nenhuma Bean Nenhuma | 19
  • Atributo NotSupported Não inicia uma nova transação A associação transacional existente é suspensaCliente T1 Container Nenhuma Bean NenhumaCliente Nenhuma Container Nenhuma Nenhuma Bean | 20
  • Atributo Mandatory Deve ser chamado de dentro de uma transação; caso contrário levanta exceçãoCliente T1 Container T1 Bean T1Cliente Container Bean Nenhuma Transaction RequiredException | 21
  • Atributo Never  Chamar um método desse tipo com uma transação em andamento gera uma exceção RemoteException Cliente T1 Container Container Bean Cliente Nenhuma Container Nenhuma Bean Nenhuma | 22
  • Transações CMT A demarcação de transação pode ser feita através de Anotations (EJB3); | 23
  • Transações CMT A demarcação de transação também pode ser feita através do arquivo ejb- jar.xml (EJB2); | 24
  • Rollback CMT Da 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 Only...@Resource SessionContext ctx;Public void inserirPaciente(Paciente p) throws PacienteJaExistenteException { ...//<regras de negócio> }catch(PacienteJaExistenteException ex) { ejbContext.setRollbackOnly(); throw ex; } 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
  • Rollback CMT Desta 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
  • Rollback OnlyPackage br.fucapi.controlemedico;@ApplicationException(rollback=true) ;Public class PacienteJaExistenteException extends Exception { public void PacienteJaExistenteException(String pNomePac){ ... }} • 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; | 28
  • Transações e Usuário Final O 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-usuá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-usuá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; Visão Processamento EJB Tela sucesso da informação Transação de BD Transação para o Usuário | 31
  • Transações e Ambientes Multi- usuários WEB O acesso/modificação concorrente ao informação por mais de um usuário põe em risco a integridade do BD; T1 (1-5 seg) T1 (06-07 seg) Edição Pessoa ProcessamentoUsuário B Cod 143 EJB Tela sucesso T1 (1-10 seg) T1 (11-12 seg) Edição Pessoa ProcessamentoUsuário A Cod 143 EJB Tela sucesso | 32
  • Transaçõ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 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