Re: [jboss-as7-dev] Better handling of transaction leaks?

From: "Jaikiran Pai" <jpai(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, October 18, 2011 11:42:30 PM Subject: Re: [jboss-as7-dev] Better handling of transaction leaks?

Just to be clear, I wasn't in favour of introducing that entire CachedConnectionValve (which definitely is quite heavy). That link was more of a reference to show how it was handled in previous versions.

Like you say, it should be easy to check the tx status with a simple check.

-Jaikiran

On Wednesday 19 October 2011 12:09 AM, Jason T. Greene wrote: > On 10/18/11 12:31 PM, Remy Maucherat wrote: >> On Tue, 2011-10-18 at 21:28 +0530, Jaikiran Pai wrote: >>> While looking into a test failure I noticed that currently user >>> applications can end up leaking transactions (associated with the >>> invocation thread): >>> >>> Servlet { >>> >>> doGet() { >>> UserTransaction.begin(); >>> doSomeOp(); >>> fail(); >>> // no tx rollback/commit >>> } >>> } >>> >>> Subsequent transactions on that thread can lead to failures and >>> other >>> sorts of issues. Looking back at previous versions of AS, we had >>> a valve >>> http://anonsvn.jboss.org/repos/jbossas/trunk/tomcat/src/main/java/org/jbo... >>> which used to cleanup (and log an error) about the leaking >>> transactions. >>> >>> Do we want something similar for AS7? Also, are there other >>> "entry >>> points" (like servlets for web requests) where such leaks can >>> happen and >>> needs to be taken care off? >> >> JPA has automatic tracking of this sort of things using a valve >> (and >> added only when needed). >> >> For the insignificant amount of people that will do manual >> transactions >> and can't be bothered to code properly, everyone gets to pay the >> cost of >> transaction tracking for all requests to the web container, so I >> am >> against this feature. >> >> I remember being flamed pretty badly for daring disabling this >> "nice" >> valve by default in AS 6 :) Hopefully it will go better this time. >> > > I'll support you (I'd rather have the perf by default). It seems > like it > should be possible to come up with a fast solution though, instead > of > using the slow CCV. For example its pretty cheap to check the UT > threadlocal and see if the status is still active (hence a leak). >

_______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev