I also now have true read only transaction that set the underlying jdbc connection to read only and FlushMode.Never for the session. And yes the read only transactions are also committed so you do not spam your database logs with rollback information.
2013/8/27 Martin Kersten <martin.kersten...@gmail.com> > Hi there, > > > after my struggle with the current @CommitAfter implementation and the > transaction handling I was able to fix it for the actual project I am > working on. I found several places where my coworker and introduced bugs > because of the current (flawed) implementation of @CommitAfter. > > (For all that do not know, the @CommitAfter annotated method suffers from > an additional commit if it is called by a method that itself is also > annotated @CommitAfter. This happens silently and most likely you are > unaware of the problem until bugs emerge introduced by broken transaction > behavior (one transaction is actually performed as many transactions)) > > To be able to change the behavior, I provided additional implementation > for the HibernateManagerImpl, HibernateTransactionAdvisorImpl and > HibernateTransactionDecoratorImpl. > > I introduced two additional annotations WriteTransaction and > ReadOnlyTransaction since I prefer strikt transaction declaration. > > > The HibernateManagerImpl does not open a new transaction by default once a > session is created. Also the session returned is wrapped by a Session > delegate enforcing the presens of a WriteTransaction for > update/save/delete/saveOrUpdate(+) methods and enforcing at least a > ReadOnlyTransaction for any other db accessing method like createQuery. > Therefore using the hibernate session object outside of a explicit > transactional context will result in a runtime exception. > > With this strikt declaration neither me nor my coworkers have the chance > to do something unintended in terms of transaction definition. > > > If someone is interested in this please give me a call. > > PS: Since tapestry does not support rebind, I just provided alternative > implementations of the Impl classes using the same name and package like > the original. Luckily Tapestry loads these instead of the one in the > hibernate module. >
