Hi Martin
You are right. Please file a jira. I will look into it this weekend.
regards
Taha
On 23-Aug-2013, at 12:41 PM, Martin Kersten <martin.kersten...@gmail.com> wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
