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.
