On Fri, Aug 23, 2013 at 11:11 AM, 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?
>
>
Not exactly. If both a() and b() are from the same interface -- then only
one transaction will be committed.
This is because tapestry wraps methods a() and b() with advices, but this
happens on the proxies, not on the implementation classes.
So if you call your method b() via proxy -- then interceptor for b() will
start the transaction, then method b() will call method a() on the
implementation class -- in this case no interceptors will be involved,
hence you won't get another transaction.
You're getting proxy references when you @Inject'ing your services.
You can see this by examining stack trace if you put a breakpoint in method
a().
But if you put method a() to Intf1 and b() to Intf2 and if you @Inject
Intf1 to Intf2 -- you should get two nested transactions.
But your database should support nested transactions.
> 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
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
