Screencast - Hibernate e Concorrência Otimista na Web com VRaptor

Screencast - Hibernate e Concorrência Otimista na Web com VRaptor
fkung
fkung

Compartilhe

É com prazer, depois de tanto tempo, que anuncio o segundo screencast da Caelum.

O vídeo trata de um dos recursos pouco explorados no Hibernate: Controle de Concorrência Otimista, para lidar com problemas de edição simultânea (concorrência) nos registros. O fato curioso é que tenho observado em diversos projetos a preferência por Locks Pessimistas, que em grande parte dos casos não são a melhor escolha. Da própria documentação do Hibernate:

The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning.

Imersão dev Back-end: mergulhe em programação hoje, com a Alura e o Google Gemini. Domine o desenvolvimento back-end e crie o seu primeiro projeto com Node.js na prática. O evento é 100% gratuito e com certificado de participação. O período de inscrição vai de 18 de novembro de 2024 a 22 de novembro de 2024. Inscreva-se já!

(...)

It is not intended that users spend much time worring about locking strategies. Its usually enough to specify an isolation level for the JDBC connections and then simply let the database do all the work.

Como podemos nos beneficiar do controle de concorrência otimista (também conhecido como lock otimista)? Para explorar o assunto, durante o screencast vamos enriquecendo uma aplicação Web existente, adicionando funcionalidades de edição simples de registros e resolvendo o problema de edição simultânea.

A aplicação Web utilizada usa e abusa do VRaptor como controlador MVC e várias dicas sobre o framework são abordadas durante o vídeo. Porém, a mensagem vale para qualquer aplicação Web. Mesmo as que não usam VRaptor.

Como sempre, o screencast mostra apenas uma das alternativas para solução do problema. Fica como lição de casa, testar outras possibildades:

1) Para não fazer o controle transacional dentro do Dao e forçar a checagem de versão (version check), no lugar do transaction.commit() poderia ter sido usado o session.lock(objeto, LockMode.READ). O método lock serve principalmente para a abordagem pessimista, porém LockMode.READ serve justamente para forçar a checagem de versão no caso otimista.

2) No lugar de tirar a entidade do cache de primeiro nível com session.evict(entidade) e consultá-la novamente para ter a versão mais nova do banco, bastaria usar o método session.refresh(entidade) que atualiza a instancia, passando direto pelos caches.

Acesse diretamente o screencast no Vimeo.

Não deixe de colocar o seu comentário com outras alternativas!

Veja outros artigos sobre Programação