Transactions and AfterCommit

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Transactions and AfterCommit

Martin Kersten
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Taha Hafeez
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

lprimak
In reply to this post by Martin Kersten
Tapestry transaction support isn't meant to be a comprehensive solution.
It can be used as a starter mechanism but if you want true transaction management,
I would recommend using full JEE server.
It doesn't support nested transactions.  

On Aug 23, 2013, at 3:11 AM, Martin Kersten <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

lprimak
Last line of my post should read
"Tapestry doesn't support nested transactions"
So to answer your question: you are right.

On Aug 23, 2013, at 3:44 AM, Lenny Primak <[hidden email]> wrote:

> Tapestry transaction support isn't meant to be a comprehensive solution.
> It can be used as a starter mechanism but if you want true transaction management,
> I would recommend using full JEE server.
> It doesn't support nested transactions.  
>
> On Aug 23, 2013, at 3:11 AM, Martin Kersten <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Dmitry Gusev
In reply to this post by Martin Kersten
On Fri, Aug 23, 2013 at 11:11 AM, Martin Kersten <
[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Dmitry Gusev
I have to correct myself, you won't get nested transactions with
@CommitAfter, because its implementation checks if another transaction is
active -- it won't start another transaction:

https://github.com/apache/tapestry-5/blob/master/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/CommitAfterMethodAdvice.java#L41-L44

    public void advise(final MethodInvocation invocation)

    {

        final EntityTransaction transaction = getTransaction();


        if (transaction != null && !transaction.isActive())

        {

            transaction.begin();

        }

But advice will still be executed, and your transaction that started by
interceptor of method b() will be committed by interceptor of method a() --
which may be not that behavior you expected, due to implementation details
of @CommitAfter:

https://github.com/apache/tapestry-5/blob/master/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/CommitAfterMethodAdvice.java#L61-L64


        if (transaction != null && transaction.isActive())
        {
            transaction.commit();
        }



On Fri, Aug 23, 2013 at 11:52 AM, Dmitry Gusev <[hidden email]>wrote:

>
>
>
> On Fri, Aug 23, 2013 at 11:11 AM, Martin Kersten <
> [hidden email]> 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
>



--
Dmitry Gusev

AnjLab Team
http://anjlab.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
In reply to this post by Taha Hafeez
TAP5-2159 <https://issues.apache.org/jira/browse/TAP5-2159>


2013/8/23 Taha Hafeez Siddiqi <[hidden email]>

> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
Thanks for taking care. Please add a post here if you find something out. I
wait for using the mentioned version to manage my transactions.


2013/8/23 Martin Kersten <[hidden email]>

> TAP5-2159 <https://issues.apache.org/jira/browse/TAP5-2159>
>
>
> 2013/8/23 Taha Hafeez Siddiqi <[hidden email]>
>
>> 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 <[hidden email]>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
@Dimitry
But using this annotation would introduce a good chance that later in your
project you introduce bugs this way. So I would consider @CommitAfter to be
a harmful feature. The problem with this transaction behavior it introduces
bugs that might happen in so rare circumstances that you always have no
chance to reproduce or spot it during debug/testing sessions.

Is there a reason why there is no @Transactional annotation dealing with
this issue like the JPA version does? The link I mentioned earlier provided
such implementation. Would be create if Tapestry 5.4 might ship along with
this. In the end I would only need this behavior that if a transaction is
present the 'inner transaction' would be ignored and only the outter
transaction remains handled. So if transaction exists, do nothing.

Is there a chance this can be introduced?

What is the desired usage of CommitAfter? I mean in my current oppinion it
is completely harmful and evil because if you are not careful you introduce
a deal breaker bug that might get your clients of the bridge. And doing
project with more then one developer you are much more likely to overlook
this effect. And I am quite certain I would be able to accidently fool my
self many more times than twice.




2013/8/23 Martin Kersten <[hidden email]>

> Thanks for taking care. Please add a post here if you find something out.
> I wait for using the mentioned version to manage my transactions.
>
>
> 2013/8/23 Martin Kersten <[hidden email]>
>
>> TAP5-2159 <https://issues.apache.org/jira/browse/TAP5-2159>
>>
>>
>> 2013/8/23 Taha Hafeez Siddiqi <[hidden email]>
>>
>>> 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 <[hidden email]>
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Thiago H de Paula Figueiredo
On Fri, 23 Aug 2013 10:45:27 -0300, Martin Kersten  
<[hidden email]> wrote:

> @Dimitry
> But using this annotation would introduce a good chance that later in  
> your project you introduce bugs this way. So I would consider  
> @CommitAfter to be a harmful feature. The problem with this transaction  
> behavior it introduces bugs that might happen in so rare circumstances  
> that you always have no
> chance to reproduce or spot it during debug/testing sessions.

I disagree. @CommitAfter never claimed to implement nested transactions,  
so, if someone expects it with @CommitAfter, they're wrong, not  
@CommitAfter. I agree that its documentation should be more explicit.

> Is there a reason why there is no @Transactional annotation dealing with
> this issue like the JPA version does? The link I mentioned earlier  
> provided such implementation. Would be create if Tapestry 5.4 might ship  
> along with this. In the end I would only need this behavior that if a  
> transaction is
> present the 'inner transaction' would be ignored and only the outter
> transaction remains handled. So if transaction exists, do nothing.

Because implementing full transaction support, like Spring and EJB do, is  
a very complex to do. Have you ever taken a look at spring-tx code? I did.  
It's quite large. Tapestry-IoC never promised to implement a full  
transaction manager. Just tapestry-hibernate and tapestry-jpa that provide  
simple transaction management because both Hibernate and JPA require  
changes to the database to be done inside a transaction.

--
Thiago H. de Paula Figueiredo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Dmitry Gusev
In reply to this post by Martin Kersten
On Fri, Aug 23, 2013 at 5:45 PM, Martin Kersten <[hidden email]
> wrote:

> @Dimitry
> But using this annotation would introduce a good chance that later in your
> project you introduce bugs this way. So I would consider @CommitAfter to be
> a harmful feature. The problem with this transaction behavior it introduces
> bugs that might happen in so rare circumstances that you always have no
> chance to reproduce or spot it during debug/testing sessions.
>
>
I don't think I have any excuse for @CommitAfter behavior, it just works
like that.

There are few simple rules you have to follow when using @CommitAfter, they
probably needs to be better explained in the documentation. But the rule of
thumb is -- don't put them on methods that may call each other.


> Is there a reason why there is no @Transactional annotation dealing with
> this issue like the JPA version does? The link I mentioned earlier provided
> such implementation. Would be create if Tapestry 5.4 might ship along with
> this. In the end I would only need this behavior that if a transaction is
> present the 'inner transaction' would be ignored and only the outter
> transaction remains handled. So if transaction exists, do nothing.
>
> Is there a chance this can be introduced?
>
>
I don't think there will be any improvements in tapestry transaction
handling.

Taha's code snippets also won't work the way you think if your methods will
be in the same class by the reason I described above.
You may write your own annotation that only does one thing that you
need, but I'd better recommend you to rethink the way your transaction
scopes intersects and maybe apply some patterns to your code that prevent
potential transaction nesting.

For instance, I've seen a lot of examples where @CommitAfter used on
page/component event handlers, so in this case you will get all your logic
executed in a single transaction. I think good rule of choosing where to
put the @CommitAfter is putting is as lower as possible down to the stack
trace. So usually the lowest level is page/component event handler.

If this doesn't work for you -- you can use Spring transactions with
tapestry, this way you don't need full JEE environment, or write your logic
with EJB and call it from tapestry services.


> What is the desired usage of CommitAfter? I mean in my current oppinion it
> is completely harmful and evil because if you are not careful you introduce
> a deal breaker bug that might get your clients of the bridge. And doing
> project with more then one developer you are much more likely to overlook
> this effect. And I am quite certain I would be able to accidently fool my
> self many more times than twice.
>
>
>

>
> 2013/8/23 Martin Kersten <[hidden email]>
>
> > Thanks for taking care. Please add a post here if you find something out.
> > I wait for using the mentioned version to manage my transactions.
> >
> >
> > 2013/8/23 Martin Kersten <[hidden email]>
> >
> >> TAP5-2159 <https://issues.apache.org/jira/browse/TAP5-2159>
> >>
> >>
> >> 2013/8/23 Taha Hafeez Siddiqi <[hidden email]>
> >>
> >>> 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 <
> [hidden email]>
> >>> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
>



--
Dmitry Gusev

AnjLab Team
http://anjlab.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
In reply to this post by Thiago H de Paula Figueiredo
>>> I disagree. @CommitAfter never claimed to implement nested
transactions, so, if someone expects it with @CommitAfter, they're wrong,
not @CommitAfter. I agree that its documentation should be more explicit.
<<<

We had this conversation in 2008 already, if I remember correctly. Same
problem, same question. The problem is that this is so easy to run into
such a bug. And you can consider it as being a broken feature. I am quite
sure if we check all of our projects there should be at least one of us
having this problem introduced just by accident (I did). I just wanted to
store a message in the system using it inside an administration service
doing something else too. So this is simple to run into it.


So lets solve this once and for all and look into the code:


current version:

public void advise(final MethodInvocation invocation)
    {
        final EntityTransaction transaction = getTransaction();

        if (transaction != null && !transaction.isActive())
        {
            transaction.begin();
        }

        try
        {
            invocation.proceed();
        } catch (final RuntimeException e)
        {
            if (transaction != null && transaction.isActive())
            {
                rollbackTransaction(transaction);
            }

            throw e;
        }

        // Success or checked exception:

        if (transaction != null && transaction.isActive())
        {
            transaction.commit();
        }

    }

New version:

public void advise(final MethodInvocation invocation)
    {
        final EntityTransaction transaction = getTransaction();

        boolean isNested = false; //<-- Change

        if (transaction != null && !transaction.isActive())
        {
            transaction.begin();
        }
        else
             isNested = true;  //<-- Change

        try
        {
            invocation.proceed();
        } catch (final RuntimeException e)
        {
            if (transaction != null && transaction.isActive() && !isNested)
//<-- Change
            {
                rollbackTransaction(transaction);
            }

            throw e;
        }

        // Success or checked exception:

        if (transaction != null && transaction.isActive() && !isNested)
//<-- Change
        {
            transaction.commit();
        }

    }

So please come on. Lets get rid of this bug! Thats all nothing more to
see... .
And its totally fools proof and downward compatible (doesnt change current
behavior).


Lets change this! And yes we can!



Cheeeers,

Martin (Kersten),
Germany


2013/8/23 Thiago H de Paula Figueiredo <[hidden email]>

> On Fri, 23 Aug 2013 10:45:27 -0300, Martin Kersten <
> [hidden email]> wrote:
>
>  @Dimitry
>> But using this annotation would introduce a good chance that later in
>> your project you introduce bugs this way. So I would consider @CommitAfter
>> to be a harmful feature. The problem with this transaction behavior it
>> introduces bugs that might happen in so rare circumstances that you always
>> have no
>> chance to reproduce or spot it during debug/testing sessions.
>>
>
> I disagree. @CommitAfter never claimed to implement nested transactions,
> so, if someone expects it with @CommitAfter, they're wrong, not
> @CommitAfter. I agree that its documentation should be more explicit.
>
>
>  Is there a reason why there is no @Transactional annotation dealing with
>> this issue like the JPA version does? The link I mentioned earlier
>> provided such implementation. Would be create if Tapestry 5.4 might ship
>> along with this. In the end I would only need this behavior that if a
>> transaction is
>> present the 'inner transaction' would be ignored and only the outter
>> transaction remains handled. So if transaction exists, do nothing.
>>
>
> Because implementing full transaction support, like Spring and EJB do, is
> a very complex to do. Have you ever taken a look at spring-tx code? I did.
> It's quite large. Tapestry-IoC never promised to implement a full
> transaction manager. Just tapestry-hibernate and tapestry-jpa that provide
> simple transaction management because both Hibernate and JPA require
> changes to the database to be done inside a transaction.
>
> --
> Thiago H. de Paula Figueiredo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
By the way one might rename it from isNested to isNestedOrNoTransaction.
Same behavior more precise in the naming


2013/8/23 Martin Kersten <[hidden email]>

> >>> I disagree. @CommitAfter never claimed to implement nested
> transactions, so, if someone expects it with @CommitAfter, they're wrong,
> not @CommitAfter. I agree that its documentation should be more explicit.
> <<<
>
> We had this conversation in 2008 already, if I remember correctly. Same
> problem, same question. The problem is that this is so easy to run into
> such a bug. And you can consider it as being a broken feature. I am quite
> sure if we check all of our projects there should be at least one of us
> having this problem introduced just by accident (I did). I just wanted to
> store a message in the system using it inside an administration service
> doing something else too. So this is simple to run into it.
>
>
> So lets solve this once and for all and look into the code:
>
>
> current version:
>
> public void advise(final MethodInvocation invocation)
>     {
>         final EntityTransaction transaction = getTransaction();
>
>         if (transaction != null && !transaction.isActive())
>         {
>             transaction.begin();
>         }
>
>         try
>         {
>             invocation.proceed();
>         } catch (final RuntimeException e)
>         {
>             if (transaction != null && transaction.isActive())
>             {
>                 rollbackTransaction(transaction);
>             }
>
>             throw e;
>         }
>
>         // Success or checked exception:
>
>         if (transaction != null && transaction.isActive())
>         {
>             transaction.commit();
>         }
>
>     }
>
> New version:
>
> public void advise(final MethodInvocation invocation)
>     {
>         final EntityTransaction transaction = getTransaction();
>
>         boolean isNested = false; //<-- Change
>
>         if (transaction != null && !transaction.isActive())
>         {
>             transaction.begin();
>         }
>         else
>              isNested = true;  //<-- Change
>
>         try
>         {
>             invocation.proceed();
>         } catch (final RuntimeException e)
>         {
>             if (transaction != null && transaction.isActive() &&
> !isNested) //<-- Change
>             {
>                 rollbackTransaction(transaction);
>             }
>
>             throw e;
>         }
>
>         // Success or checked exception:
>
>         if (transaction != null && transaction.isActive() && !isNested)
> //<-- Change
>         {
>             transaction.commit();
>         }
>
>     }
>
> So please come on. Lets get rid of this bug! Thats all nothing more to
> see... .
> And its totally fools proof and downward compatible (doesnt change current
> behavior).
>
>
> Lets change this! And yes we can!
>
>
>
> Cheeeers,
>
> Martin (Kersten),
> Germany
>
>
> 2013/8/23 Thiago H de Paula Figueiredo <[hidden email]>
>
>> On Fri, 23 Aug 2013 10:45:27 -0300, Martin Kersten <
>> [hidden email]> wrote:
>>
>>  @Dimitry
>>> But using this annotation would introduce a good chance that later in
>>> your project you introduce bugs this way. So I would consider @CommitAfter
>>> to be a harmful feature. The problem with this transaction behavior it
>>> introduces bugs that might happen in so rare circumstances that you always
>>> have no
>>> chance to reproduce or spot it during debug/testing sessions.
>>>
>>
>> I disagree. @CommitAfter never claimed to implement nested transactions,
>> so, if someone expects it with @CommitAfter, they're wrong, not
>> @CommitAfter. I agree that its documentation should be more explicit.
>>
>>
>>  Is there a reason why there is no @Transactional annotation dealing with
>>> this issue like the JPA version does? The link I mentioned earlier
>>> provided such implementation. Would be create if Tapestry 5.4 might ship
>>> along with this. In the end I would only need this behavior that if a
>>> transaction is
>>> present the 'inner transaction' would be ignored and only the outter
>>> transaction remains handled. So if transaction exists, do nothing.
>>>
>>
>> Because implementing full transaction support, like Spring and EJB do, is
>> a very complex to do. Have you ever taken a look at spring-tx code? I did.
>> It's quite large. Tapestry-IoC never promised to implement a full
>> transaction manager. Just tapestry-hibernate and tapestry-jpa that provide
>> simple transaction management because both Hibernate and JPA require
>> changes to the database to be done inside a transaction.
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transactions and AfterCommit

Martin Kersten
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Transactions-and-AfterCommit-td5722996.html

If you look at this solution, I also ask myself why there is no direct
support. I can not believe that this is not needed in any way. Why should I
go for spring or fuddle with my code to just be able to mark something as
transactional and maybe do something like read-only transaction in
hibernate?

This would save my day.

As far as I remember I barely saw someone using something different than
hibernate (or jdbc) when it comes to sql. So if tapestry would support
Hibernate's transactional capabilities (and be quite fair all we need are
nested transaction awareness (well its not a true nested transaction just a
nested annotation of CommitAfter, nested transactions are a bit more
complicated and are supported nowhere :)) and ReadOnly transactions thats
all).

An Idea:
@Transaction
and
@ReadOnly @Transaction

Transaction works like CommitAfter and ReadOnly is just a marker for the
transaction to begin a read only transaction. That's it. It shouldnt be
hard to support this.

Maybe ReadOnly might be renamed like @ReadOnlyHibernateTransaction and
@HibernateTransaction. Who knows.

What do you think. Anyone likes this or not? Or is there something similar
already present. Would love to know.

I dont need JTA transactions at all.

Also ReadOnlyHibernateTransaction can be implented as getting the session
and set the connection to read only and session to FLUSH_NEVER.

In case of a Master/Slave replication how does tapestry's current solution
work in terms of ReadOnly transactions or is everything annotated with
CommitAfter is automatically hitting the master all the time? What happens
with the session interaction that is not annotated with @CommitAfter. Is it
executed statement by statement (autocommit?) and are those hitting always
the master too?


2013/8/23 Martin Kersten <[hidden email]>

> By the way one might rename it from isNested to isNestedOrNoTransaction.
> Same behavior more precise in the naming
>
>
> 2013/8/23 Martin Kersten <[hidden email]>
>
>> >>> I disagree. @CommitAfter never claimed to implement nested
>> transactions, so, if someone expects it with @CommitAfter, they're wrong,
>> not @CommitAfter. I agree that its documentation should be more explicit.
>> <<<
>>
>> We had this conversation in 2008 already, if I remember correctly. Same
>> problem, same question. The problem is that this is so easy to run into
>> such a bug. And you can consider it as being a broken feature. I am quite
>> sure if we check all of our projects there should be at least one of us
>> having this problem introduced just by accident (I did). I just wanted to
>> store a message in the system using it inside an administration service
>> doing something else too. So this is simple to run into it.
>>
>>
>> So lets solve this once and for all and look into the code:
>>
>>
>> current version:
>>
>> public void advise(final MethodInvocation invocation)
>>     {
>>         final EntityTransaction transaction = getTransaction();
>>
>>         if (transaction != null && !transaction.isActive())
>>         {
>>             transaction.begin();
>>         }
>>
>>         try
>>         {
>>             invocation.proceed();
>>         } catch (final RuntimeException e)
>>          {
>>             if (transaction != null && transaction.isActive())
>>             {
>>                 rollbackTransaction(transaction);
>>             }
>>
>>             throw e;
>>         }
>>
>>         // Success or checked exception:
>>
>>         if (transaction != null && transaction.isActive())
>>         {
>>             transaction.commit();
>>         }
>>
>>     }
>>
>> New version:
>>
>> public void advise(final MethodInvocation invocation)
>>     {
>>         final EntityTransaction transaction = getTransaction();
>>
>>         boolean isNested = false; //<-- Change
>>
>>         if (transaction != null && !transaction.isActive())
>>         {
>>             transaction.begin();
>>         }
>>         else
>>              isNested = true;  //<-- Change
>>
>>         try
>>         {
>>             invocation.proceed();
>>         } catch (final RuntimeException e)
>>         {
>>             if (transaction != null && transaction.isActive() &&
>> !isNested) //<-- Change
>>             {
>>                 rollbackTransaction(transaction);
>>             }
>>
>>             throw e;
>>         }
>>
>>         // Success or checked exception:
>>
>>         if (transaction != null && transaction.isActive() && !isNested)
>> //<-- Change
>>         {
>>             transaction.commit();
>>         }
>>
>>     }
>>
>> So please come on. Lets get rid of this bug! Thats all nothing more to
>> see... .
>> And its totally fools proof and downward compatible (doesnt change
>> current behavior).
>>
>>
>> Lets change this! And yes we can!
>>
>>
>>
>> Cheeeers,
>>
>> Martin (Kersten),
>> Germany
>>
>>
>> 2013/8/23 Thiago H de Paula Figueiredo <[hidden email]>
>>
>>> On Fri, 23 Aug 2013 10:45:27 -0300, Martin Kersten <
>>> [hidden email]> wrote:
>>>
>>>  @Dimitry
>>>> But using this annotation would introduce a good chance that later in
>>>> your project you introduce bugs this way. So I would consider @CommitAfter
>>>> to be a harmful feature. The problem with this transaction behavior it
>>>> introduces bugs that might happen in so rare circumstances that you always
>>>> have no
>>>> chance to reproduce or spot it during debug/testing sessions.
>>>>
>>>
>>> I disagree. @CommitAfter never claimed to implement nested transactions,
>>> so, if someone expects it with @CommitAfter, they're wrong, not
>>> @CommitAfter. I agree that its documentation should be more explicit.
>>>
>>>
>>>  Is there a reason why there is no @Transactional annotation dealing with
>>>> this issue like the JPA version does? The link I mentioned earlier
>>>> provided such implementation. Would be create if Tapestry 5.4 might ship
>>>> along with this. In the end I would only need this behavior that if a
>>>> transaction is
>>>> present the 'inner transaction' would be ignored and only the outter
>>>> transaction remains handled. So if transaction exists, do nothing.
>>>>
>>>
>>> Because implementing full transaction support, like Spring and EJB do,
>>> is a very complex to do. Have you ever taken a look at spring-tx code? I
>>> did. It's quite large. Tapestry-IoC never promised to implement a full
>>> transaction manager. Just tapestry-hibernate and tapestry-jpa that provide
>>> simple transaction management because both Hibernate and JPA require
>>> changes to the database to be done inside a transaction.
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
Loading...