Try to avoid CommitAfter its broken beyond repair (Accidently nesting the annotation creates unexpected commit behaviour that is hard to spot).
If you do batch work you should use session.getTransaction().commit() instead to control the session. Hibernate also has some problems regarding to shared transaction manager (you can find a line 'return null; //???' related to this. Try to use: ((SessionImpl)hibernateSession).setAutoClear(true); This way the session will be auto cleared after each commit/rollback. This is also necessary when using Hibernate with JDBC transactions (no addtional transaction manager like JTA) and expecting JPA / EJB3 behaviour (session auto-clear). For the slow down you can use a profiler and check the memory consumption and the active objects after some time. You might see entity objects still be referenced. Since you said you clear your session I wonder if clear does what you expect if you do not commit the transaction before clear(). Here is a answer of a question that might related to the slowing down: http://stackoverflow.com/questions/10143880/hibernate-queries-much-slower-with-flushmode-auto-until-clear-is-called/18948517#18948517 Cheers Martin (Kersten), Germany 2013/10/25 George Christman <gchrist...@cardaddy.com> > I'm wondering how to do a batch transaction with Tapestry-Hibernate. Should > I still be using @Inject Session session and @CommitAfter? or Should I be > using Transaction tx? I'm flushing and clearing my session every 200 > iterations, but it appears to progressively get slower and slower until I > restart the job. Any thoughts on this? > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York >
