Como controlar transações concorrentes no TomCat?

Front-end
#1

Bom dia pessoal,
vou migrar um sistema que tenho em Delphi
para Flex + BlaseDS + tomcat/Java/Hibernate, estou na fase de
estudo/escolha de FrameWorks de trabalho, ai me deparei como o
problema das transações concorrentes, já pesquisei na documentação
do hibernate e, ou crio um campo versão na minha tabela, ou uso alguns
controles do hibernate para gerenciar transações concorrentes, achei a
opção de criar um campo um tanto quanto gambiarra, me desculpem a
franqueza, ai fui para a segunda opção mas reparei que ela só funcionará
se eu tiver usando a mesma session do banco, ai vem a pergunta:

Tem como com requests diferente na mesma sessão do tomcat manter a
mesma session do hibernate?

Não sei se me fiz entender e posso estar falando besteira.

Desde já Obrigado.
Sandro Mueller

#2

da uma olhada em POLL de Conexão, no caso do Hibernate você poder user o c3po.

#3

mesmo vc precisando de dados de várias telas o commit só vai acontecer em um momento, então vc não precisa de uma sessão com o banco tão longa. o que vc precis a é manter em sessão sua regra de negócio ou seus objetos de negócio. Ou seja, os dados coletados vão durar mais que um request para que após várias telas (requests) vc ainda tenha essa informação em mãos.

pesquise o framework vraptor, q roda facinho em cima do tomcat, é simples e tem um exemplo de login persistido na sessão q é a mesma idéia.

#4

Não sei se entendi sua pergunta, mas para isso não basta deixar a sessão do hibernate aberta e bota-la na session da request?

#5

sessões do hibernate devem ter vida curta! recomendações deles mesmos :wink:

se ele realmente precisar de várias regras de negócio espalhadas E que façam parte de uma mesma transação, aí é o caso RARO de usar EJB3.

#6

sessões do hibernate devem ter vida curta! recomendações deles mesmos :wink:

se ele realmente precisar de várias regras de negócio espalhadas E que façam parte de uma mesma transação, aí é o caso RARO de usar EJB3. [/quote]

Verdade… Verdade! li a pergunta rapidamente e não parei pra pensar.

#7

Oi Pessoal,
primeiramente obrigado a todos pela colaboração.

Bom vamos ao resumo, pelo que entendi eu posso “vincular” a sessão do Hibernate com a Sessão do meu request(tomcat),
entretanto esta pratica não é aconselhada devido ao fato das sessões do Hibernate deverem ter vida curta, então vem a pergunta:
Como é feito o controle de transações concorrentes? usam aquele controle de versão(criação de uma campo) na tabela?

Desde já, Obrigado.
Sandro Mueller

#8

[quote=Sandro Mueller]Oi Pessoal,
primeiramente obrigado a todos pela colaboração.

Bom vamos ao resumo, pelo que entendi eu posso “vincular” a sessão do Hibernate com a Sessão do meu request(tomcat),
entretanto esta pratica não é aconselhada devido ao fato das sessões do Hibernate deverem ter vida curta, então vem a pergunta:
[/quote]
na verdade vc pode fazer o que quiser, desde que a sessão do hibernate seja curta.
Existe um padrão que se chama “open-session-in-view”, onde a sessão do hibernate irá iniciar quando o usuáro, por exemplo, fizer alguma requisição na view e terminará quando, por exemplo, o tomcat finalizar a respota dessa requisição, lógico tudo automatizado. acho q esse é seu caso.
tem essa apostila q cobre essa parte muito bem:

eu não entendi o que vc quis dizer com transações concorrentes.
quando nos referimos a transações no hibernate significa: tudo que estiver num determinado pedaço de código ou é todo executado ou nada é executado… para garantir a consistencia da operação. é isso q vc está se referindo?

#9

[quote=bobmoe]
eu não entendi o que vc quis dizer com transações concorrentes.
quando nos referimos a transações no hibernate significa: tudo que estiver num determinado pedaço de código ou é todo executado ou nada é executado… para garantir a consistencia da operação. é isso q vc está se referindo?[/quote]

Oi cara tudo bem,
bom transações concorrentes é o seguinte:

Imagine dois usuários(usuário A e usuário B) que querem alterar o mesmo registro de determinada entidade/tabela
o usuário A vai lá e lê o registro e enquanto ele está alterando na tela o usuário B vai lá e pega o mesmo registro tbm,
ai o A salva primeiro e o B salva logo após, as alterações feitas pelo usuário A serão perdidas…

Se vc tiver um controle de transações concorrente, na hora de salvar o usuário B recebera uma exceção explicando a
situação.

Sandro Mueller

#10

[quote=Sandro Mueller][quote=bobmoe]
eu não entendi o que vc quis dizer com transações concorrentes.
quando nos referimos a transações no hibernate significa: tudo que estiver num determinado pedaço de código ou é todo executado ou nada é executado… para garantir a consistencia da operação. é isso q vc está se referindo?[/quote]

Oi cara tudo bem,
bom transações concorrentes é o seguinte:

Imagine dois usuários(usuário A e usuário B) que querem alterar o mesmo registro de determinada entidade/tabela
o usuário A vai lá e lê o registro e enquanto ele está alterando na tela o usuário B vai lá e pega o mesmo registro tbm,
ai o A salva primeiro e o B salva logo após, as alterações feitas pelo usuário A serão perdidas…

Se vc tiver um controle de transações concorrente, na hora de salvar o usuário B recebera uma exceção explicando a
situação.

Sandro Mueller
[/quote]
isso eu sei :slight_smile: mas valeu!!! eu queria saber dentro do seu sistema como vc usava isso.

qualquer sgbd moderno cuida disso… não é algo que vc precisa implementar o conceito. só q vc precisa indicar para o banco onde essa transação começa e onde ela termina.
no hibernate isso é sinalizado da seguinte maneira:

Transaction tx = null; try { tx = sessao.beginTransaction(); debito(contaDebito);//exemplo credito(contaCredito);//exemplo tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; }

o q vc precisa entender é q o conceito de transação aqui é ineficaz para uma operação. talvez o q vc esteja querendo controlar é a ordem de chegada das atualizações.
ou seja, enquanto vc pedir uma atualização para o banco, aqla tabela vai recber um lock e não vai deixar outra pessoa atualisar o proximo campo antes de temrinar todo seu update. mas é só isso. agora ele não controla quem vai pegar essa tarefa primeiro.

aqui explica com mais detalhes a concorrencia no hinernate:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/transactions.html

#11

portanto… vc não tem um problema de concorrencia, já que o banco nunca deixa, por exemplo, outro update entrar no meio do update atual… garantindo assim a integridade das operações.
vc quer controlar a ordem das atualizações, ou seja quem chega primeiro tem que temrinar primeiro. mas seria mais uma questão de escalonamento ou chegada.

#12