I review some code and I ran into the transaction issue. Annotating a
service @CommitAfter seams to be inappropriate if you have another service
method using it and is itself annotated with the @CommitAfter.
The problem I have seams within the documentation. For @CommitAfter the
documentation states that the transaction is committed at the end of the
method.
Therefore I think that for the case:
@CommitAfter
a() {...}
@CommitAfter
b() { a(); }
At least two commits will happen for each of those commits. Am I right here?
There is the PersitenceContext annotation and that somehow I can use it to
control transactional behavior but In my oppinion this focus about using a
second session for two different persistent contexts. Am I right on this
one?
So in the end it looks like programming or using some other sort of
mechanism that is aware of nested logical transactions and ignores the
commit inside an ongoing transaction. This behavior can be introduced using
HibernateSessionManager.
There is also this post
http://tawus.wordpress.com/2011/04/23/tapestry-magic-5-advising-services/which
describes exactly what I need.
The question here is there anything shipped with tapestry that allows this
kind of behavior or am I missunderstanding @CommitAfter and this behavior
is already present?
Is there a standard way to control whether there is a ReadOnly transaction
going on or not? I didnt found anything about it. Maybe I am blind. :)
Cheers and Thank you,
Martin (Kersten),
Germany
