On Fri, Aug 23, 2013 at 5:45 PM, Martin Kersten <martin.kersten...@gmail.com > 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 <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 > >>> > >>> > >> > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
