[Dúvida] Por que consultas não precisam de Transações?

Vc tem um código aí?

Oi,

Entenda transação como o seguinte:

Execução de comandos que podem alterar o banco de dados, onde, caso algum dos comandos não realize com sucesso, os demais sejam desfeitos. Transação garante a atomicidade e integridade de um método.

Quando tu apenas faz consultas, você não está escrevendo no banco, estã apenas consultando o banco, e este não exige que uma transação seja aberta para gerenciar esta execução, conhecido por transações somente leitura (o que torna muito mais rapido, pois não será necessário que o banco efetue um jornal das execuções (para prover o rollback)). Mas isso tudo depende do seu driver JDBC e banco de dados.

É mais ou menos por aí…

peerless:

Oi,

Entenda transação como o seguinte:

Execução de comandos que podem alterar o banco de dados, onde, caso algum dos comandos não realize com sucesso, os demais sejam desfeitos. Transação garante a atomicidade e integridade de um método.

Quando tu apenas faz consultas, você não está escrevendo no banco, estã apenas consultando o banco, e este não exige que uma transação seja aberta para gerenciar esta execução, conhecido por transações somente leitura (o que torna muito mais rapido, pois não será necessário que o banco efetue um jornal das execuções (para prover o rollback)). Mas isso tudo depende do seu driver JDBC e banco de dados.

É mais ou menos por aí…

falou pouco, mas falou bunito.

Na verdade consulta usa transação implicita

Bem, pelo visto você está falando do conceito de transação no Hibernate. Este conceito, denominado pelo Hibernate de unidade de trabalho, é mais abrangente do que o conceito de transação em SGBD. Tanto é que o Hibernate recomenda que mesmo consultas sejam executadas dentro de uma unidade de trabalho(transação). Na prática o hibernate através do driver JDBC, implementa uma unidade de trabalho através de transações(caso necessário) no banco e armazenando informações de controle também em memória.

Uma transação em um banco de dados tem que garantir a famosa ACID(Atomicidade, Consistência, Isolamento e Durabilidade). Como um SGDB é, normalmente, um sistema com concorrência, os dados devem ser preservados íntegros, apesar de vários acessos de leitura e escrita ao mesmo tempo. É responsabilidade dele manter isso, além de abstrair dos seus clientes os acessos concorrentes de vários usuários. Uma consulta, em si, já é atômica, ou seja, ou é executada por completo ou não. Além disso, operações de leitura não alteram a base. Os protocolos de controle de concorrência, como os de bloqueio e de controle de versão, se encarregam de realizar este controle, nos SGDB’s.

Abraços…

Obrigado a todos pela atenção.
Então eu posso concluír como:
Consultas utilizam transações implicitas.
Já as transações utilizadas por comandos de update são mais abrangentes de modo que o Hibernate necessite utilizar recursos para conseguir garantir a ACID (Atomicidade, Consistência, Isolamento e Durabilidade) do Banco de dados. Seria Isso?

Então quando eu faço uma consulta, o hibernate por debaixo dos panos abre uma transação mais simples do que o normal e realiza a consulta?

Fora, que vocês falaram que é indicado usar a transação do Hibernate mesmo para as consultas. Qual o motivo?

A documentação de referência do hibernate explica bem a relação entre uma unidade de trabalho e uma transação de banco de dados:
http://docs.jboss.org/hibernate/core/3.6/reference/pt-BR/html/transactions.html#transactions-basics

Aqui podemos encontrar o motivo.
http://community.jboss.org/wiki/Non-transactionalDataAccessAndTheAuto-commitMode

Nem o Hibernate nem o SGDB tem como saber em uma transação se ocorrerá, ou não, uma escrita. Logo, seria necessário que o usuário fornecesse uma informação a eles de que a operação será somente leitura. Como recomendado pelo Hibernate,isso só deve ser feito se existir um grande benefício de performance.

Espero ter ajudado.

Helder Neres