A interface org.hibernate.Transaction obriga a implementacao de metodos interessantes para o tratamento de transacoes, sao eles: begin(), commit(), rollback(), wasRolledBack(), wasCommitted(), isActive(), registerSynchronization(Synchronization synchronization) e setTimeout(int seconds).Uma boa e comumente utilizada implementacao dessa interface e JDBCTransaction. Porem essa implementacao na minha opiniao tem um pequeno problema que, embora nao tenha prejuizos a e nao interfira a execucao correta do sistema, deveria ser corrigido, inclusive pretendo sugerir para a Hibernate Community um ajuste com relacao a isso.Pule esse trecho se dominar o try/catch:Em java temos a opcao de tornar nossa aplicacao mais robusta atraves do bloco try/catch e do conjunto de excecoes e classes que extendem java.lang.Exception. O try/catch tambem nos da flexibilidade de criar e manipular nossas proprias excecoes fazendo o tratamento de fluxos anormais do sistema. Isso pode ser usado, e frequentemente e, em Fluxos de excecoes por exemplo, validacoes de negocio e outras ocasioes em que nao se deseja seguir o fluxo normal do sistema.Veja rapidamente a sintaxe:try { //Executando algo perigoso (algo que pode lancar uma excecao declarada ou nao) metodoPerigoso();} catch(MinhaExcecaoException e) { //Obrigatorio no minimo um catch por try //tratando excecao MinhaExcecaoException quando ela ocorrer} //Podem haver varios blocos catch, contando que as excecoes mais restritivas venham antes das mais abrangentesfinally {//O bloco finally e opcional mas se for inserido sempre sera executado, mesmo que nenhuma excecao seja lancada.}Agora veja em detalhes o que nao gostei na implementacao JDBCTransaction.Atraves de um SessionFactory ("Fabrica de sessoes". Objeto responsavel por oferecer sessoes (nesse caso Hibernate), utilizando o Design pattern Factory para isso) obtive uma sessao e fiz o commit de uma transacao: final Session sessao = sessionFactory.openSession(); try { sessao.beginTransaction(); final SQLQuery query = sessao.createSQLQuery("insert into TABELA_XXX values(?, ?)"); query.setParameter(0, "param1");// Exemplo de um parametro string, que sera aplicado ao primeiro '?' acima int param2 = 3L;//So um exemplo de um parametro query.setParameter(1, param2);// param2 sera aplicado ao segundo '?' query.executeUpdate(); sessao.save(entidade);//Fazendo outra transacao, salvando uma entidade por exemplo. sessao.getTransaction().commit(); sessao.flush(); } catch (final RuntimeException e) { sessao.getTransaction().rollback(); //Faz outros tratamentos } catch (final Exception e) { sessao.getTransaction().rollback(); LOG.severe(e.getLocalizedMessage()); } finally { fecharSessao(sessao); }OK, tudo certo, se conseguir executar a transacao ta ok, se der alguma excecao eu faco rollback, possivelmente registro log, e sempre havendo ou nao erro, fecho a sessao.Mas se houver uma excecao eu mesmo quero tratar, da forma que eu quiser, nao quero que nada seja feito alem do que eu fizer. O problema que eu falei e que isto nao ocorre.O sessao.getTransaction() do codigo acima retorna o objeto org.hibernate.Transaction que pode fazer o commit e quando ha uma excecao, em algum lugar da pilha de metodos executada no commit() e chamado um printStackTrace.Esse metodo imprime na saida padrao, a pilha de excecoes ocorridas. Por mais que eu queira tratar da minha forma, e a forma que quero nao inclui a impressao do statckTrace, nao ha como fazer.De qualquer forma ira imprimir o printStackTrace caso haja uma excecao javax.sql.SQLException por exemplo.Por isso quando escrever um codigo, pense bem antes de colocar algo do tipo. Deixe que o programador trate do jeito que quiser, apenas lance