JPA Demonstração das estratégias optimistic locking e pessimistic locking

Transcrição

1 JPA Demonstração das estratégias optimistic locking e pessimistic locking Locking é uma técnica para tratamento de concorrência em transações em bases de dados. Quando duas ou mais transações em bases de dados acedem ao mesmo dado, locking permite assegurar que apenas uma transação de cada vez consegue mudar esse dado. Em JPA há duas estratégias para tratar o locking: optimistic locking pessimistic locking. Como exemplo vamos considerar as atualizações do saldo de uma conta após dois depósitos realizados aproximadamente ao mesmo tempo. programa1 programa2 Inicia transação Inicia transação Lê objeto Lê objeto Efetua depósito 1 Efetua depósito 2 Efetua commit Efetua commit Quando dois programas podem modificar o mesmo dado, se ambos os programas realizam a sequência ler-modificar-escrever de um modo intercalado podem corromper esse dado. Só o último depósito afeta o saldo perdendo-se a primeira modificação.

2 Setup 1. H2 em modo servidor para permitir múltiplas ligações simultâneas configurar driver na Unidade de Persistência Configurar h2 para modo Servidor preencher JDBC URL com JDBC URL: jdbc:h2:tcp://localhost/~/bd/contas Ficheiro persistence.xml: <?xml version="1.0" encoding="utf-8"?> <persistence version="2.1" xmlns=" xmlns:xsi=" xsi:schemalocation=" <persistence-unit name="jpa2pu" transaction-type="resource_local"> <provider>org.eclipse.persistence.jpa.persistenceprovider</provider> <class>conta</class> <properties> <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/bd/contas"/> <property name="javax.persistence.jdbc.user" value=""/> <property name="javax.persistence.jdbc.driver" value="org.h2.driver"/> <property name="javax.persistence.jdbc.password" value=""/> <property name="javax.persistence.schema-generation.database.action" value="create"/> <property name="eclipselink.logging.level.sql" value="fine"/> <property name="eclipselink.logging.parameters" value="true"/> </properties> </persistence-unit> </persistence> 2. Criar as classes Conta, Iniciar, Util, UtilizadorA e public class Conta { // private int versionid = GenerationType.IDENTITY) private int id; private double saldo; private Conta() { public Conta(double depositoinicial) { this.saldo = depositoinicial; public int getid() { return id; public double getsaldo() { return saldo; public void depositar(double deposito) { saldo += deposito;

3 public class Iniciar { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); Conta conta = new Conta(100); em.persist(conta); em.gettransaction().commit(); em.close(); emf.close(); public class Util { public static void parar(string msg) { try { System.out.println(msg); System.in.read(); catch (Exception e) { public class UtilizadorA { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); Conta conta = em.find(conta.class, 1); Util.parar("A: Saldo=" + conta.getsaldo() + " Continuar?"); conta.depositar(20); Util.parar("A: Saldo=" + conta.getsaldo() + " Continuar?"); em.gettransaction().commit(); em.close(); emf.close(); System.out.println("A (Fim) - Saldo: " + conta.getsaldo());

4 public class UtilizadorB { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); Conta conta = em.find(conta.class, 1); Util.parar("B: Saldo=" + conta.getsaldo() + " Continuar?"); conta.depositar(30); Util.parar("B: Saldo=" + conta.getsaldo() + " Continuar?"); em.gettransaction().commit(); em.close(); emf.close(); System.out.println("B (Fim) - Saldo: " + conta.getsaldo()); 3. Executar o método main da classe Iniciar A base de dados é criada. 4. Iniciar h2 em modo servidor Iniciar o servidor de h2: h2\bin\h2.bat Inspecionar a base de dados criada usando a página H2 Console

5 Sem Locking 5. Classe Conta sem atributo version. Executar intercaladamente os métodos main da classe UtilizadorA e da classe public class Conta { // private int versionid = GenerationType.IDENTITY) private int id; private double saldo;... Aplicação funciona incorretamente: Só o último depósito afeta o saldo perdendo-se a primeira modificação.

6 Com Optimistic Locking Para usar a estratégia otimista é necessário adicionar uma propriedade dedicada à persistência para guardar na base de dados o número da versão da entidade. Esse campo de dados versão: Não deve ser modificado pela aplicação Pode ser numérico ou timestamp mas um valor numérico é recomendado É definido pela ou pelo elemento <version> No commit da transação a coluna versão da entidade: Na estratégia optimistic é incrementada se o estado da entidade mudou durante a transação Na estratégia optimistic_force_increment é incrementada mesmo se o estado da entidade não mudou durante a transação Em qualquer uma das duas estratégias otimistas, se no commit da transação, a entidade tem na base de dados uma versão diferente da versão que tinha quando foi carregada, uma exceção OptimisticLockingException é lançada, significando que outro thread entretanto modificou a entidade. Podemos apanhar esta exceção e decidir o que fazer. O locking otimista deixa transações concorrentes processar simultaneamente, permitindo ler e atualizar uma entidade, mas deteta colisões, verificando no commit se a versão foi atualizada na base de dados desde que a entidade foi lido, caso em que lança uma exceção. A estratégia otimista deve ser usada quando se assume que a maior parte das transações concorrentes não entram em conflito. As vantagens desta estratégia são não necessitar de colocar locks na base de dados o que dá melhor escalabilidade. A desvantagem é que a aplicação deve refrescar e voltar a tentar atualizações que falhem. Locking de uma entidade Existem 5 tipos de locking: OPTIMISTIC OPTIMISTIC_FORCE_INCREMENT PESSIMISTIC_READ PESSIMISTIC_WRITE PESSIMISTIC_FORCE_INCREMENT

7 6. Classe Conta com atributo version Alteração apenas da classe Conta para inclusão do atributo versionid. Programa termina com exceção lançada Sem try catch Necessário criar novamente a base de dados porque agora a tabela Conta tem mais uma coluna (versionid) Executar intercaladamente os métodos main da classe UtilizadorA e da classe UtilizadorB Aplicação funciona incorretamente Método main do UtilizadorB: UPDATE CONTA SET SALDO =?, VERSIONID =? WHERE ((ID =?) AND (VERSIONID =?)) bind => [130.0, 2, 1, 1] O segundo método main termina com exceção lançada: The object [jpa2.conta@d109c4f] cannot be updated because it has changed or been deleted since it was last read.

8 Só o primeiro depósito afeta o saldo perdendo-se a última modificação. Com try catch public class UtilizadorC { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); boolean depositado = false; do { try { em.gettransaction().begin(); Conta conta = em.find(conta.class, 1); // em.lock(conta, LockModeType.PESSIMISTIC_READ); Util.parar("C: Saldo=" + conta.getsaldo() + " Continuar?"); conta.depositar(30); Util.parar("C: Saldo=" + conta.getsaldo() + " Continuar?"); em.gettransaction().commit(); depositado = true; catch (final Exception e) { System.out.println("Saldo mudou desde que foi lido. Tente outra vez."); while (!depositado); em.close(); emf.close();

9 Aplicação funciona corretamente SELECT ID, SALDO, VERSIONID FROM CONTA WHERE (ID =?) bind => [1] UPDATE CONTA SET SALDO =?, VERSIONID =? WHERE ((ID =?) AND (VERSIONID =?)) bind => [150.0, 3, 1, 2] Com Pessimistic Locking 7. Configurar as aplicaçãoes com a estratégia pessimistic locking O lock numa entidade é colocado pelo EntityManager (em). Pode ser especificado: Quando a entidade é carregada da base de dados através do método find Pessoa pessoa = em.find(pessoa.class, pessoapk, LockModeType.OPTIMISTIC); Através do método refresh em.refresh(person, LockModeType.OPTIMISTIC_FORCE_INCREMENT); Quando carregada através de uma query: Query query = em.createquery(...); query.setlockmode(lockmodetype.pessimistic_force_increment); Depois de ser carregada da base de dados: em.lock(entity, LockModeType.PESSIMISTIC_READ);

10 O modo lock de uma entidade pode ser obtido: LockModeType modolock = em.getlockmode(entity); No locking pessimistic, em vez de esperar até ao commit da transação, na esperança de que nenhuma outra transação tenha mudado os dados, um lock na base de dados é obtido imediatamente. Assim a transação nunca falha, contudo também não permite execução paralela de transações. O locking pessimistic é efetuado ao nível da base de dados enquanto o locking optimistic é efetuado ao nível da entidade. Locks pessimistas são propagados para a base de dados usando queries SQL. Se existe um lock pessimista, a aplicação espera pela base de dados até o lock ser liberto, não lançando exceção. public class UtilizadorA { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); Conta conta = em.find(conta.class, 1); em.lock(conta, LockModeType.PESSIMISTIC_READ); Util.parar("A: Saldo=" + conta.getsaldo() + " Continuar?"); conta.depositar(20); Util.parar("A: Saldo=" + conta.getsaldo() + " Continuar?"); em.gettransaction().commit(); em.close(); emf.close(); public class UtilizadorB { public static void main(string[] args) throws InterruptedException { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA2PU"); EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); Conta conta = em.find(conta.class, 1); em.lock(conta, LockModeType.PESSIMISTIC_READ); Util.parar("B: Saldo=" + conta.getsaldo() + " Continuar?"); conta.depositar(30); Util.parar("B: Saldo=" + conta.getsaldo() + " Continuar?"); em.gettransaction().commit(); em.close(); emf.close();

11 Executar intercaladamente os métodos main da classe UtilizadorA e da classe UtilizadorB UtilizadorA: SELECT ID, SALDO, VERSIONID FROM CONTA WHERE (ID =?) FOR UPDATE bind => [1] UtilizadorB: SELECT ID, SALDO, VERSIONID FROM CONTA WHERE (ID =?) FOR UPDATE bind => [1] org.h2.jdbc.jdbcsqlexception: Timeout trying to lock table. Caused by: org.h2.jdbc.jdbcsqlexception: Concurrent update in table "CONTA": another transaction has updated or deleted the same row [ ] Caused by: java.lang.illegalstateexception: Entry is locked [ /101] O método main da classe UtilizadorB termina com exceção lançada devido a Timeout. A ligação (EntityManager) deste programa não consegue obter um lock na base de dados porque outra ligação (EntityManager de UtilizadorA) mantém o lock. Para obter o lock seria necessário que a ligação do utilizadora libertasse o lock durante o lock timeout cujo valor, por omissão, é 1000 ms. O lock timeout pode ser colocado individualmente para cada ligação ou para toda a aplicação na Persistence Unity : <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/bd/contas;lock_timeout=80000"/> Ficheiro persistence.xml: <?xml version="1.0" encoding="utf-8"?> <persistence version="2.1"... > <persistence-unit name="jpa2pu" transaction-type="resource_local"> <provider>org.eclipse.persistence.jpa.persistenceprovider</provider> <class>jpa2.conta</class> <properties> <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/bd/contas;lock_timeout=80000"/> <property name="javax.persistence.jdbc.user" value=""/> <property name="javax.persistence.jdbc.driver" value="org.h2.driver"/>... </properties> </persistence-unit> </persistence>

12 Agora as aplicações funcionam corretamente Começamos por executar a classe Iniciar para colocar o objeto conta com a versão 1 Em seguida executamos intercaladamente os métodos main da classe UtilizadorA e da classe UtilizadorB, mas a classe UtilizadorB não consegue avançar porque não consegue obter um lock na base de dados UtilizadorA: SELECT ID, SALDO, VERSIONID FROM CONTA WHERE (ID =?) FOR UPDATE bind => [1] UPDATE CONTA SET SALDO =?, VERSIONID =? WHERE ((ID =?) AND (VERSIONID =?)) bind => [120.0, 2, 1, 1]

13 Após a ligação do UtilizadorA libertar o lock na base de dados, o programa do UtilizadorB avança. UtilizadorB: SELECT ID, SALDO, VERSIONID FROM CONTA WHERE (ID =?) FOR UPDATE bind => [1] UPDATE CONTA SET SALDO =?, VERSIONID =? WHERE ((ID =?) AND (VERSIONID =?)) bind => [150.0, 3, 1, 2] A principal vantagem de usar pessimistic locking é a garantia de que, uma vez o lock obtido, a edição terá sucesso. Útil em aplicações altamente concorrentes nas quais optimistic locking poderia causar muitos erros de locking optimistic. Uma desvantagem de usar pessimistic locking é que necessita de recursos adicionais da base de dados, obrigando a transação e a ligação à base de dados serem mantidas durante a edição.