@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 <martin.kersten...@gmail.com> > 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 <martin.kersten...@gmail.com> > >> TAP5-2159 <https://issues.apache.org/jira/browse/TAP5-2159> >> >> >> 2013/8/23 Taha Hafeez Siddiqi <tawus.tapes...@gmail.com> >> >>> 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 >>> >>> >> >
