On Fri, Oct 8, 2010 at 11:32 AM, Rich M <rich...@moremagic.com> wrote: > Ah, darn it. This is for a vital product and my company wouldn't let me use > 5.2 until its a final release. However, a little bit of digging I was able > to improve on my previous code for 5.1.0.5. Albeit no @CommitAfter, but it > does seem a better solution that using Transaction explicitly (which results > in Tapestry-Hibernate exceptions). Basically replace Transaction with ... > Hopefully this is useful to some people trying to use Tapestry-Hibernate in > 5.1.0.5, but also encountering issues with @CommitAfter and not liking the > way Tapestry-Hibernate complains when you manage Transaction on your own.
Better do it right if you don't wish to heed the collective wisdom that is tapestry-hibernate and want to manage transactions yourself. Tapestry-Hibernate only complains if you are stealing the transaction that is supposed to be managed for you. There are perfectly valid cases where you want to manage the transactions, but you can also mix and match with managed and unmanaged transactions provided that you do it carefully. In principle, there are two cases: 1) If you want the transaction to participate in the same session, open a new transaction after you close the managed transaction - there can be more to commit in the same request cycle 2) For a background or a delayed operation, create a new session instead of trying to use the managed session (with HibernateSessionSource.create()) and manage transactions in that session yourself Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
