Transações, Controle de Concorrência e o Hibernate. Clodis Boscarioli

Transcrição

1 Transações, Controle de Concorrência e o Hibernate Clodis Boscarioli

2 Transações Um conjunto de várias operação em um BD pode ser visto pelo usuário como uma única unidade. Exemplo: A transferência de fundos de uma conta corrente pra uma conta poupança é uma operação única do ponto de vista do cliente, porém, dentro do sistemas de banco de dados, ela envolve várias operações. É essencial que todo o conjunto de operações seja concluído, ou que, no caso de uma falha, nenhuma delas ocorra. Um SGBD precisa: Garantir que a execução da transação seja completa; Administrar a execução simultânea de várias transações evitando inconsistências; Uma transação que calcula o total de dinheiro do cliente poderia trabalhar com o saldo da conta corrente antes do débito feito pela transação de transferência e, também, verificar o saldo da poupança depois do crédito. Com isso, obteria um resultado incorreto.

3 Operações de escrita/leitura As operações de acesso ao BD que uma transação pode fazer são: read(x): que transfere o item de dados x do BD para um buffer local alocado à transação que executou a operação de read. O valor de x é colocado dentro de uma variável de programa. write(x): que transfere o item de dados x do buffer local da transação que executou o write de volta para o BD. O valor da variável de programa é passado para o item de dado no BD. OBS.: para fins de simplificação, representaremos o item de dados e a variável de programa correspondente da mesma forma: x.

4 Execução das operações Executar read(x): Encontrar o endereço do bloco de disco que contém x; Copiar este bloco de disco para dentro do buffer/memória principal, se ele já não estiver lá; Copiar o item x do buffer para a variável de programa. Executar write(x): Encontrar o endereço do bloco de disco que contém x; Copiar o bloco de disco para a memória principal se ele já não estiver lá; Copiar o item x da variável de programa x para a localização correta no buffer; Copiar o bloco alterado do buffer de volta para o disco (imediatamente ou mais tarde).

5 Exemplo de transação A) read(x); x := x N; write(x); read(y); y := y + N; write(y); B) read(x); x := X + M; write(x); T1 T2 Acesso concorrente ao dado x.

6 Exemplo: Seja T1 uma transação que transfere 50 reais da conta A para a conta B. Essa transação pode ser definida como: Ti: read(a); A := A - 50; write(a); read(b); B := B + 50; write(b);

7 Propriedades das transações (ACID) A Atomicidade: ou todas as operações da transação são refletidas corretamente no banco de dados ou nenhuma o será. Suponha que, durante a execução da transação Ti, uma falha aconteça impedindo Ti de se completar com sucesso (uma queda de energia). Suponha ainda que a falha tenha ocorrido depois da execução da operação write(a), mas antes da operação write(b). O que acontece? O estado do sistema não reflete mais um estado real do mundo que se supões representado no BD. É um estado inconsistente. Estes estados não podem ser perceptíveis, ou seja, estados inconsistente só são permitidos no momento de execução da transação, onde o usuário não terá qualquer tipo de acesso aos dados. Assegurar a atomicidade de uma transação é responsabilidade do SGBD, mais especificamente, do Componente de Gerenciamento de Transações e Recuperador de Falhas.

8 Propriedades das transações (ACID) C - Consistência: a execução de uma transação isolada (ou seja, sem a execução concorrente de outra transação) preserva a consistência do banco de dados. A exigência da consistência aqui significa que a soma de A com B deve permanecer inalterada após a execução da transação. Se o banco de dados está consistente antes de uma execução de transação, o banco de dados permanece consistente após a execução da transação. Responsabilidade do programador.

9 Propriedades das transações (ACID) I Isolamento: embora diversas transações possam ser executadas de forma concorrente, o sistema garante que, para todo par de transações Ti e Tj, Ti tem a sensação de que Tj terminou sua execução antes de Ti começar, ou vice-versa. Cada transação não toma conhecimento de outras transações concorrentes a ela no sistema. A execução concorrente de várias transações implica no intercalamento de suas operações. Se este intercalamento é feito de forma inconveniente, inconsistências serão geradas. No exemplo dado, se uma transação concorrente ler o valor de A antes dele ser escrito mais depois do processamento A-50 ter sido feito, ela estará lendo um valor inconsistente. Execuções em série resolvem este problema mas a concorrência é benéfica por causa do tempo de execução (melhora do desempenho). Assegurar o isolamento é de responsabilidade do Controlador de Concorrência.

10 Propriedades das transações (ACID) D Durabilidade: depois da transação completar-se com sucesso, as mudanças que ela faz no banco de dados persistem, até mesmo se houver falhas no sistema. No exemplo dado, se a transação se completar com sucesso e o usuário que a disparou for notificado da transferência de fundos, isso significa que não houve nenhuma falha de sistema que tenha resultado em perda de dados relativa a essa transferência. Assegurar a durabilidade é responsabilidade do componente do SGBD chamado de Recuperador de Falhas.

11 Transações Operações Uma transação é uma unidade de trabalho atômica que é completada em sua totalidade ou nada dela deve ter efeito. Para tornar isso possível, as seguintes operações são necessárias: Begin-transaction: marca o início da execução da transação; End-transaction: especifica que as operações da transação terminaram e marca o limite final da execução da transação. Neste ponto é necessário verificar se o COMMIT ou o ABORT são necessários, caso já não tenham sido explicitados; Commit-transaction: sinal de término com sucesso e que as alterações podem ser permanentemente gravadas no BD; Rollback (abort-transaction): sinal que a transação não terminou com sucesso e que seus efeitos devem ser desfeitos; Undo: desfaz uma operação; Redo: refaz uma operação.

12 Exemplo: begin transaction update TABELA1 set CAMPO1 = NOVO VALOR where CAMPO2 = 35 <> 0 rollback else commit end transaction Suponha que a tabela possua 6000 registros que satisfaçam a condição e que no registro 4666 houve uma falha no sistema. Neste caso, a variável guardará o código do erro, o comando ROLLBACK será executado e os 4666 registros já atualizados serão automaticamente voltados ao seu estado anterior. Ao contrário, se tudo correr bem, o comando COMMIT será executado e todos os 6000 registros que atenderam à condição serão atualizados com êxito.

13 Estados de uma transação Read/Write Begin Transaction Ativa End Transaction Em efetivação parcial Efetivada Abort Abort Em falha Completa Diagrama de transição de estados para a execução da transação. Com sucesso ou com falha.

14 Considerações Uma transação entra no estado de falha quando o sistema determina que ela já não pode prosseguir sua execução normal. Essa transação deve ser desfeita e entra no estado de abortada. Nesse momento o sistema tem duas opções: Reiniciar a transação: somente se ela foi abortada como resultado de algum erro de hardware ou de software não criado pela lógica interna da transação. Uma transação reiniciada é considerada uma transação nova. Matar a transação: normalmente, isto é feito em decorrência de algum erro lógico interno e só pode ser corrigido refazendo o programa de aplicação. Esse erro dá-se ou porque a entrada de dados não era adequada ou porque os dados desejados não foram encontrados no banco de dados.

15 Execução concorrente Sejam T1 e T2 duas transações que transferem fundos de uma conta para outra. A transação T1 transfere 50 dólares da conta A para a conta B. A transação T2 transfere 10 por cento do saldo da conta A para a conta B.

16 Execução Concorrente T1: read(a); A := A 50; write(a); read(b); B := B + 50; write(b); T2: read(a); temp := A * 0,1; A := A temp; write(a); read(b); B := B + temp; write(b);

17 Execução Seqüencial Escalas de execução em seqüência: observe que o estado do BD é sempre consistente. T1 T2 T1 T2 read(a); A := A 50; write(a); read(b); B := B + 50; write(b); read(a); temp := A * 0,1; A := A temp; write(a); read(b); B := B + temp; write(b); read(a); A := A 50; write(a); read(b); B := B + 50; write(b); read(a); temp := A * 0,1; A := A temp; write(a); read(b); B := B + temp; write(b);

18 Execução Concorrente... Correta Incorreta T1 T2 T1 T2 read(a); A := A 50; write(a); read(a); temp := A * 0,1; A := A temp; write(a); read(a); A := A 50; read(a); temp := A * 0,1; A := A temp; write(a); read(b); B := B + 50; write(b); read(b); B := B + temp; write(b); write(a); read(b); B := B + 50; write(b); read(b); B := B + temp; write(b);

19 Problema de alterações perdidas Ocorre quando duas transações que acessam o mesmo item de BD possuem suas operações intercaladas de uma maneira que o valor de algum item de dado fique incorreto. T1 read(x); x := x - N; write(x); read(y); T2 read(x) x := x + M; write(x) y := y + N; write(y)

20 Problema de alteração temporária Ocorre quando uma transação altera um item de dados e depois ela falha por alguma razão. O item de dado é acessado por outra transação antes que o valor original seja estabelecido. T1 read(x); x := x - N; write(x); T2 read(x) x := x + M; write(x) falha read(y);

21 Problema do resumo incorreto Se uma transação está calculando uma função agregada com um conjunto de registros e outras transações estão alterando alguns destes registros, a função agregada pode calcular alguns valores antes deles serem alterados e outros depois de serem alterados. T1 read(x); x := x - N; write(x); read(y); y := y + N; write(y) T3 sum := 0; read(a); sum : sum + a; read(x) sum := sum + x; read(y); sum := sum + y;

22 Serialização O sistema de banco de dados deve controlar a execução concorrente de transações para assegurar que o estado do BD permaneça consistente. A consistência do banco de dados, sob execução concorrente, pode ser assegurada por meio da garantia de que qualquer escala executada tenha o mesmo efeito de outra que tivesse sido executada sem qualquer concorrência. Isto é, uma escala de execução deve, de alguma forma, ser equivalente a uma escala seqüencial.

23 Serialização por Conflito Considere uma escala de execução S com duas instruções sucessivas, I i e I j, das transações T i e T j (i <> j), respectivamente. Se I i e I j referem-se a itens de dados diferentes, então é permitido alternar I i e I j sem afetar os resultados de qualquer instrução da escala. Se I i e I j referem-se ao mesmo item de dado Q, então a ordem dos dois passos pode importar.

24 Serialização por Conflito 1. Ii = read(q) e Ij = read(q) A seqüência de execução de I i e I j não importa, já que o mesmo valor de Q é lido por Ti e Tj, independentemente da ordem destas operações. 2. Ii = read(q) e Ij = write(q) Se I i vier antes de I j, então T i não lê o valor de Q que é escrito por T j na instrução I j. Se I j vier antes de I i, então T i lê o valor de Q que é escrito por T j. Assim, a ordem de I i e I j importa.

25 Serialização em Conflito 3. Ii = write(q) e Ij = read(q) A ordem de I i e I j importa por razões semelhantes às do caso anterior. 4. Ii = write(q) e Ij = write(q) Como ambas as instruções são operações de escrita, a ordem dessas instruções não afeta T i ou T j. Entretanto, o valor obtido pela próxima instrução read(q) em S é afetado, já que somente o resultado da última das duas instruções write(q) é preservado no banco de dados. Se não houver nenhuma outra instrução de write(q) depois de I i e I j em S, então a ordem de I i e I j afeta diretamente o valor final de Q no que se refere ao estado do banco de dados após a execução da escala S.

26 Serialização em Conflito Diz-se que duas instruções entram em conflito se elas são operações pertencentes a transações diferentes, agindo no mesmo item de dado, e pelo menos uma dessas instruções é uma operação de escrita. T1 read(a) write(a) read(b) write(b) T2 read(a) write(a) read(b) write(b) A instrução write(a) de T1 entra em conflito com a instrução read(a) de T2. Porém, a instrução write(a) e T2 não está em conflito com a instrução read(b) de T1.

27 Serialização em Conflito Seja I i e I j instruções consecutivas de uma escala de execução S. Se I i e I j são instruções de transações diferentes e não entram em conflito, então podemos trocar a ordem de I i e I j para produzir uma nova escala de execução S. Diz-se que S e S são equivalentes já que todas as instruções aparecem na mesma ordem em ambas as escalas de execução com exceção de I i e I j, cuja ordem não importa.

28 Serialização em Conflito Ainda segundo a escala S, a instrução write(a) de T2 não entra em conflito com a instrução read(b) de T1. Então, é permitido mudar a ordem dessas instruções para gerar uma escala de execução equivalente. T1 read(a) write(a) read(b) write(b) T2 read(a) write(a) read(b) write(b) Em relação a um mesmo estado inicial do sistema, ambas as escalas (S e esta) produzem o mesmo estado final no sistema.

29 Serialização em Conflito Se as seguintes trocas de instruções não-conflitantes forem feitas: read(b) de T1 por read(a) de T2; write(b) de T1 por write(a) de T2; write(b) de T1 por read(a) de T2... uma escala com execuções seriais será obtida. Assim mostrou-se que a escala S é equivalente, por conflito, a uma escala seqüencial. Essa equivalência garante que para um mesmo estado inicial do sistema, a escala S produzirá o mesmo estado final produzido por essa escala seqüencial.

30 Serialização por Conflito Se uma escala de execução S puder ser transformada em outra, S, por uma série de trocas de instruções não-conflitantes, dizemos que S e S são equivalentes por conflito. O conceito de equivalência por conflito leva ao conceito de serialização por conflito. Uma escala de execução S é serializável por conflito se ela é equivalente por conflito a uma escala de execução seqüencial.

31 Serialização por Conflito A escala abaixo não é serializável por conflito pois não é equivalente em conflito nem à escala seqüencial <T3,T4> nem <T4,T3>. T3 T4 read(a) write(a) write(a)

32 Serialização por Conflito A escala abaixo não é serializável por conflito, mas produz o mesmo resultado que uma escala seqüencial. Confira. T1 T2 read(a); A := A 50; write(a); read(b); B := B 10; write(b); read(b); B := B + 50; write(b); read(a); A := A + 10; write(a);

33 Teste de serialização por conflito Seja S uma escala. Para saber se ela é serializável em relação às operações conflitantes é necessário criar um grafo de precedência para S. G = (V,E) em que V é um conjunto de vértices e E é um conjunto de arestas. O conjunto de vértices é composto por todas as transações que participam da escala. O conjunto de arestas consiste em todas as arestas Ti Tj para as quais uma das seguintes condições é verdadeira: Ti executa write(q) antes de Tj executar read(q); Ti executa read(q) antes de Tj executar write(q); Ti executa write(q) antes de Tj executar write(q);

34 Teste de serialização por conflito Se existir uma aresta Ti tj no grafo de precedência, então, em qualquer escala seqüencial S equivalente a S, Ti deve aparecer antes de Tj. Exemplo: T1 T2 read(a); A := A 50; write(a); read(b); B := B + 50; write(b); read(a); temp := A * 0,1; A := A temp; write(a); read(b); B := B + temp; write(b); T1 T2

35 Teste de serialização por conflito Exemplo: T1 read(a) A := A - 50 write(a) read(b) B := B + 50 write(b) T2 read(a) temp := A * 0,1 A := A temp write(a) read(b) B := B + temp; write(b) T1 T2 Ciclo no grafo: se o grafo de precedência possui ciclo, então a escala S não é serializável por conflito. A ordem de serialização pode ser obtida por meio da classificação topológica, que estabelece uma ordem linear para a escala consistente com a ordem parcial do grafo de precedência.

36 API para Transações - Hibernate Session session = sessions.opensession(); Transaction tx = null; //org.hibernate.transaction try { tx = session.begintransaction(); //Abre Transação acaoexecutada1(); acaoexecutada2(); acaoexecutada3(); tx.commit(); //Confirma Transação } catch (Exception e) { tx.rollback(); //Desfaz operações em caso de erro }finally { session.close(); }

37 Flushing Processo de sincronizar os dados em sessão (memória) com o banco de dados; Sincronização nem sempre ocorre no commit(); Mudanças no escopo do Session não são propagadas imediatamente para o banco de dados.

38 Flushing Flushing ocorre quando: Quando é dado commit na transação; Quando o método Session.flush() é executado; Algumas ocasiões quando uma consulta é executada (onde alterações influenciam o resultado da consulta).

39 Flushing com commit Session sessao = sf.opensession(); Transaction tx = sessao.begintransaction(); Autor autor = (Autor) sessao.get(autor.class, 10); System.out.println(autor.getNome()); autor.setnome( José da Silva"); System.out.println("Antes Commit"); tx.commit(); sessao.close();

40 Flushing com commit Hibernate: select autor0_.id_autor as id1_0_0_, autor0_.nome as nome0_0_, autor0_. as 0_0_, autor0_.endereco as endereco0_0_, autor0_.sexo as sexo0_0_ from Autor autor0_ where autor0_.id_autor=? José da Silva Antes Commit Hibernate: update Autor set nome=?, =?, endereco=?, sexo=? where id_autor=?

41 Flushing com Session.flush() Session sessao = sf.opensession(); Transaction tx = sessao.begintransaction(); Autor autor = (Autor) sessao.get(autor.class, 10); System.out.println(autor.getNome()); autor.setnome( José da Silva"); sessao.flush(); System.out.println("Antes Commit"); tx.commit(); sessao.close();

42 Flushing com Session.flush() Hibernate: select autor0_.id_autor as id1_0_0_, autor0_.nome as nome0_0_, autor0_. as 0_0_, autor0_.endereco as endereco0_0_, autor0_.sexo as sexo0_0_ from Autor autor0_ where autor0_.id_autor=? José da Silva Hibernate: update Autor set nome=?, =?, endereco=?, sexo=? where id_autor=? Antes Commit

43 Flushing com Consulta Session sessao = sf.opensession(); Transaction tx = sessao.begintransaction(); Autor autor = (Autor) sessao.get(autor.class, 10); System.out.println(autor.getNome()); autor.setnome( José da Silva"); Criteria criteria = sessao.createcriteria(autor.class); criteria.add(expression.eq("nome", " José da Silva ")); Autor autorbd = (Autor) criteria.uniqueresult(); if (autorbd == null){ System.out.println("Nao existe"); }else{ System.out.println("Existe = " + autorbd.getnome()); } System.out.println("Antes Commit"); tx.commit(); sessao.close();

44 Modos de Flushing Definidos a partir de Session.setFlushMode(): FlushMode.AUTO: Padrão. Flush antes das consultas apenas se alterações dentro da transação alterar seus resultados. FlushMode.COMMIT: Sincronização do estado em memória com o BD apenas no fim da transação. Chamada ao commit. FlushMode.MANUAL: Sincronização feita apenas com chamada explícita do método flush().

45 Níveis de Isolamento de uma Transação Especifica quais dados estão visíveis a uma sentença dentro de uma transação; Pode-se usar: Processo de locking: bloqueio temporário de acesso a um dado; Modelo MCC: Multiversion Concorrency Control.

46 Fenômenos Devido à Quebra de Isolamento Dirty Read (Leitura Suja): Uma transação (1) consegue acessar Modificações feitas por outra transação (2) ainda não finalizada; As duas transações 1 e 2 ocorrem concorrentemente; Pode ocorrer erro durante a transação 2 (antes do commit) e transação 1 trabalhar com dados incorretos.

47 Níveis de Isolamento de uma Transação Nonrepeatable Read (Leitura quenão pode ser repetida): Uma transação lê o mesmo dado duas vezes e constata que as leituras possuem valores diferentes: Transação A lê linha x; Transação B lê e modifica linha x e finaliza a transação; Transação A lê novamente linha x; Transação A possui duas leituras de x com valores diferentes.

48 Níveis de Isolamento de uma Transação Phantom Read (Leitura Fantasma): Na mesma transação uma consulta é executada mais de uma vez e retorna resultados diferentes.

49 Níveis de Isolamento

50 Read Uncommited: Não Recomendado, pois lê inconsistências e informações parciais; Para bancos de dados somente leitura.

51 Read Commited: Transação 1 só visualiza dados modificados na transação 2 se a transação 2 tiver sido finalizada. Transação só acessa dados consistentes; Se a transação 2 der erro, transação 1 realiza atualização de acordo com dado anterior; Se transação 2 der certo: Transação 1 ignora atualização se linha tiver sido excluída ou; Transação 1 aplica atualização considerando dado atualizado pela transação 2.

52 Repeatable Read: Não permite que uma transação sobrescreva os dados alterados por uma transação concorrente; Serializable: Nível mais rigoroso; Execução serial das transações.

53 Configurando o Nível de Isolamento Níveis: 1: Read Uncommited 2: Read Commited 4: Repeatable Read 8: Serializable Configurando no hibernate.cfg.xml: <property name="hibernate.connection.isolation"> 2 </property>

54 Controle de Concorrência Quando uma ou mais transações que ocorrem concorrentemente acessam e atualizam o mesmo dado, isso pode gerar inconsistência. Deve-se, portanto, controlar a concorrência!

55 Mecanismos de Locking Pessimista: T1 lê um dado e tem a intenção de atualizá-lo; O dado será bloqueado e liberado somente após a atualização. Otimista: T1 lê um dado, porém o mesmo não é bloqueado; Caso T2 tenha lido o dado concorrentemente com T1 e tente atualizá-lo após T1, ocorrerá um erro de violação de concorrência.

56

57 Locking Otimista Utilização do Padrão Version Number; Versionar numericamente os dados de uma linha de uma tabela.

58

59 Locking Otimista package dominio; = "conta_corrente ) public class ContaCorrente { //Atributo utilizado para = "versao") private int versao; = = GenerationType.AUTO) private int id; private double saldo; //...

60 Locking Otimista Dentre os diversos atributos da classe está o atributo denominado versao, do tipo inteiro, que irá guardar a versão atual das linhas da tabela. A tabela conta_corrente também deve ter uma coluna para onde esse atributo versao será mapeado: CREATE TABLE conta_corrente ( id_conta_corrente integer NOT NULL, saldo numeric(16,2) NOT NULL, versao integer NOT NULL, CONSTRAINT pk_conta_corrente PRIMARY KEY (id_conta_corrente) ) WITHOUT OIDS; ALTER TABLE conta_corrente OWNER TO postgres; De acordo com o mapeamento feito na classe ContaCorrente, toda vez que uma determinada linha for atualizada na base de dados, a sua coluna versao será incrementada de uma unidade, indicando a nova versão dos dados.

61 Locking Otimista //... Transaction tx = session.begintransaction(); ContaCorrente conta = new ContaCorrente(); conta.setsaldo(1000); //Persistência do objeto conta session.save(conta); tx.commit(); //... Considere a criação de um objeto ContaCorrente, que é persistido na base de dados. A tupla será inserida e a versão atual da mesma será zero, correspondendo à primeira versão.

62 Locking Otimista //... Transaction tx = session.begintransaction(); ContaCorrente conta = (ContaCorrente) session.get(contacorrente.class, 65); //Modificando valor do saldo conta.setsaldo(12250); //Atualizacao do objeto conta corrente session.saveorupdate(conta); tx.commit(); //... Essa operação atualiza os dados da conta corrente, que tem a coluna versao incrementada de uma unidade, atualizando assim a informação de versionamento da tupla da tabela.

63 Locking Otimista Outra forma de implementar o lock otimista é utilizando um atributo que represente a versão do dado como sendo do tipo timestamp. Neste caso, a classe ContaCorrente citada ao invés de ter um atributo inteiro para guardar a versão do dado, teria uma atributo do tipo java.util.date para guardar o instante no tempo da última atualização. Neste exemplo, a tabela conta_corrente deve conter uma coluna do tipo timestamp denominada data_ultima_atualizacao.

64 Locking guardando data e hora //... //Atributo utilizado para = private Date data; //...

65 Locking Otimista 3ª Abordagem Se a tabela não possuir uma coluna para guardar a versão do dado ou a data da última atualização, com Hibernate, há uma outra forma de implementar o lock otimista, porém essa abordagem só deve ser utilizada para objetos que são modificados e atualizados em uma mesma sessão (Session).

66 Locking Otimista 3ª = optimisticlock = OptimisticLockType.ALL, dynamicupdate = true) public class ContaCorrente { //Atributos = = GenerationType.AUTO) private int id; private double saldo; //Outros atributos e Métodos getters e setters //... }

67 Locking Otimista 3ª Abordagem Nessa abordagem, quando uma determinada linha vai ser atualizada, o Hibernate verifica se os dados dessa linha correspondem aos mesmos dados que foi recuperado. Caso afirmativo, a atualização é efetuada. Para isso, no mapeamento da tabela, deve-se utilizar o atributo optimisticlock = OptimisticLockType.ALL da além da anotação javax.persistence.entity.

68 Locking Otimista 3ª Abordagem UPDATE CONTA_CORRENTE SET SALDO = 1500 WHERE ID_CONTA = 104 AND SALDO = 1000 AND DESCRICAO = "DESCRICAO DA CONTA" AND ID_CORRENTISTA = 23 Em uma atualização solicitada na tabela, a SQL equivalente seria gerada para a atualização. Neste exemplo, considera-se a atualização do saldo para R$ 1.500,00 de uma determinada conta de saldo R$ 1.000,00.

69 Locking Pessimista Bloqueio do dado usado por uma transação até ela ser finalizada; Utiliza a construção SQL SELECT FOR UPDATE para bloquear o dado até que o mesmo seja atualizado. Exemplo: //Sem Lock Transaction tx = session.begintransaction(); Aluno aluno = (Aluno) session.get(aluno.class, alunoid); aluno.setnome("novo Nome"); tx.commit();

70 Locking Pessimista // Exemplo com Lock Transaction tx = session.begintransaction(); Aluno aluno = (Aluno) session.get( Aluno.class, alunoid, LockMode.UPGRADE); aluno.setnome("novo Nome"); tx.commit();

71 Locking Pessimista O Hibernate fornece um conjunto de modos de lock (constantes disponíveis na classe LockMode) que podem ser utilizados para implementar o lock pessimista. O método get do objeto Session pode receber como terceiro argumento para implementar o lock pessimista as constantes a seguir.

72

73 Locking Pessimista Lock.NONE: Só realiza a consulta ao banco se o objeto não estiver no cache. Lock.READ: Ignora os dados no cache e faz verificação de versão para assegurar-se de que o objeto em memória é o mesmo que está no banco. Lock.UPDGRADE: Ignora os dados no cache, faz verificação de versão (se aplicável) e obtém lock pessimista do banco (se suportado). Lock.UPDGRADE_NOWAIT: Mesmo que UPGRADE, mas desabilita a espera por liberação de locks, e dispara uma exceção se o lock não puder ser obtido. Caso especial do Oracle que utiliza a cláusula SELECT... FOR UPDATE NOWAIT para realizar locks. Lock.WRITE: Obtida automaticamente quando o Hibernate realiza alguma inserção ou atualização na base de dados.

74 Fontes Bibliográficas: Sistemas de Banco de Dados. (Cap. 13) Abraham Silberchatz, Henry F. Korth, S Sudarshan. 3a Ed. Makron Books, Sistemas de Banco de Dados. (Cap. 17) Ramez Elmarsri e Sham Navathe. 4a Ed. Pearson, Java Persistence com Hibernate. Christian Bauer, Gavin King. Editora Ciência Moderna, Hibernate com Anotações. Raphaela Galhardo Fernandes, Gleydson de A. Ferreira Lima. Apostila, 2007.