It's broken. Or at least one should update the UserGuide stating out the concrete behaviour and the danger that can be caused by using it in conjunction with Services.
I had to clean up the mess that was introduced by using this annotation on Service interfaces. And luckily this even breaks the transaction isolation since Hibernate does not do auto-clean the session unless its in JPA mode or JTA is used. Since those bugs are hard to spot I logged all misuse and broken transactions and it where more then one hundred distinct (!) broken path in a single test suite run. And I do not think my Indian coworker intentionally misused this annotation and he is doing tapestry for more then five years now (imagen all the broken projects he created). The problem is that running on few user does not cause much of problems but going on multiple users or high volume sites (kind of thousands concurrently)... . So this is by way the most dangerous annotation I have seen in my whole career. Periode. And I can not understand why it is in place? Who does transactional behaviour to be controlled by marking the commit point at the end of a method by annotating the method start point and do not value nested transactions? One should update the UserGuide for this. My coworker thought about having a single transaction but luckily as @CommitAfter states he had more then 20 commits in the longer interaction phases. This is broken by design. If people use it and unintentionally does not got it right, then this is broken or at least the documentation is creating false confidence. You do not want to know the costs (hours + delay) this stupid misunderstanding caused and I see the same miss-understanding on many people. Create some warning notes in the documentation please. I even saw this wrong usage in bigger firms with well trained guys. (beside the Indian coworker is very smart also). I felt for the same trap in 2008 when I was looking for a transactional annotation... . 2013/10/25 Lance Java <lance.j...@googlemail.com> > Martin, again you are saying @CommitAfter is broken when it's not. It's > your understanding of @CommitAfter that is broken :) > > CommitAfter does exactly what is says on the tin, it commits the current > transaction after it executes the method. >
