@George: Flushing the session does not commit your changes (Consider FlushMode.Commit). Therefore clear does not clear the persistence context. The rest is just dedicated to O(n²) for dirty checking (even immutable objects are dirty checked and touched in the way I wrote within the stackoverflow answer).
So the solution is simply committing after now and then to speed up the batch process. Maybe you can do some benchmarking and check when and how often a commit (+ clear) is sufficient. @Thiago Sure but the early Tapestry advertised with being a Web Framework shipping with out of the box Hibernate support. Maybe sometimes you need to include a knife with your fork... . 2013/10/25 Thiago H. de Paula Figueiredo <thiag...@gmail.com> > On Fri, Oct 25, 2013 at 10:53 AM, Barry Books <trs...@gmail.com> wrote: > > While it's true you can run into problems by nesting @CommitAfter the same > > can be said about nesting any commits. The Tapestry database model is > > simple. There is one connection per request and when you call commit it > > does a commit. > > > > <pedantic> > Tapestry itself doesn't have any database model. It's a web framework and > nothing else. You can use it with any database, including none. > Tapestry-Hibernate is a package that provides *simple* support for > Hibernate and should be used in *simple* scenarios. If you need something > that's not simple, like any transaction handling not supported by > @CommitAfter, use Tapestry and some transaction handler (EJB, Spring-TX, > etc) but not Tapestry-Hibernate. > </pedantic> > > > > > > > > > On Fri, Oct 25, 2013 at 7:31 AM, Lance Java <lance.j...@googlemail.com > > >wrote: > > > > > I'm assuming a fork is broken too because it's no good for eating soup? > > > Sounds like you need a spoon, it's easy to write your own annotation... > > > Perhaps you want a @MaybeCommitAfter ;) > > > > > > > > > -- > Thiago >
