Ainda não tem acesso? Estude com a gente! Matricule-se
Ainda não tem acesso? Estude com a gente! Matricule-se

Solucionado (ver solução)

Transação não commitada

Uma coisa que eu não entendi foi porque a transação não é commitada. Como usuário JPA a algum tempo, sempre que vou escrever algo no banco é sempre o mesmo ritual:

tx.begin();
//escrita
tx.commit();

No curso: a transação é aberta, as alterações são feitas e depois só é dado um rollback e fecha a sessão.

@Before
public class setUp(){
    tx.begin();
}

@After
public class setDown(){
    tx.rollback();
}

Por que não existe a necessidade do tx.commit(); ?

2 respostas

Rithyelle,tudo bem ?

Não queremos efetivar a transação, contudo senão me falha a memoria você pode fazer o commit e em seguida dar o rollback.

solução

Matheus, até onde eu sei o commit e o rollback são excludentes - ou você executa um ou o outro.

Isso porque ambos fecham a transação, e com resultados antagônicos - o commit fecha a transação gravando os dados no bando de dados, enquanto que o rollback fecha descartando todas as alterações efetuadas durante essa transação.

A resposta da dúvida original se deve ao fato do JPA manter o cache em memória atualizado com as últimas alterações efetuadas na sessão - podemos pesquisar como se os objetos já estivessem sido gravados no banco - ao final, podemos executar o rollback sem gravar nada - afinal de contas, é apenas um teste.

Executaríamos commit apenas no caso de querermos persistir nossas alterações no banco de dados - o que o código de produção ao qual a Rithyelle se referiu e que está acostumada.

Espero ter ajudado.

Abraços.