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

Prezados,
A pergunta é exatamente essa...."Por que consultas não necessitam a abertura de transações"?

Uma transação não é necessária sempre que você faz "Uma ida até o banco e volta"?
Seja para um delete, update, insert....Você teve de ir ao banco e voltar. A diferença é que teve de dar Commit para Persistir os dados.

Porém, um getSession().beginTransaction() não é necessário quando se faz Consultas... Por quê?
Uma consulta também não necessita ir até o banco e voltar?

Estou tento uma visão errada sobre transações?
Alguém pode me explicar melhor...se possível de maneiras objetivas e sem tentar me enrrolar?^^

Abraços!!!

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4191 Offline

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í..

JavaEvangelist Membro desde: 08/10/2011 11:18:37 Mensagens: 413 Offline

peerless wrote: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.

Virtual Machine Man Membro desde: 10/08/2006 16:22:17 Mensagens: 530 Offline

Na verdade consulta usa transação implicita

Debugger Membro desde: 16/02/2008 16:58:38 Mensagens: 52 Offline

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?

Debugger Membro desde: 16/02/2008 16:58:38 Mensagens: 52 Offline

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?

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

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

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

Many more issues must be considered when you introduce nontransactional data access in your application. We?ve already noted that introducing a new type of transaction, namely read-only transactions, can significantly complicate any future modification of your application. The same is true if you introduce nontransactional operations.

You would then have three different kinds of data access in your application: in regular transactions, in read-only transactions, and now also nontransactional, with no guarantees. Imagine that you have to introduce an operation that writes data into a unit of work that was supposed to only read data. Imagine that you have to reorganize operations that were nontransactional to be transactional.

Our recommendation is to not use the autocommit mode in an application, and to apply read-only transactions only when there is an obvious performance benefit or when future code changes are highly unlikely. Always prefer regular ACID transactions to group your data-access operations, regardless of whether you read or write data.

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?

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

Notícias, artigos e o maior fórum brasileiro sobre Java