Como controlar transações concorrentes no TomCat?

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

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.

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?

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

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.

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

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.

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

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

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:

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?

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?

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

Sandro Mueller:

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?

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

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

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.