Hibernate Transaction Safetyness

[Martin Kersten <ma...@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.

Re: Hibernate Transaction Safetyness

[Martin Kersten <ma...@gmail.com>]

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 <ma...@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.
>