Solucionado
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(); ?
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.
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.