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

[Andrig Miller]

I want to make sure that whatever is done with this stuff, is that it is configurable in such a way that it can be removed for our benchmarking purposes, and performance tuning in general. 

Even a lightweight check will add overhead that we cannot afford if we are to be competitive with IBM and Oracle on SPECjEnterprise2010. Besides, this is a debugging exercise, not something that should ever really be on in a production environment, in my opinion. 

Andy 

----- Original Message -----

> From: "Jaikiran Pai" <jpai at redhat.com>
> To: jboss-as7-dev at 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/jboss/web/tomcat/service/jca/CachedConnectionValve.java
> >>> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111019/2c44b752/attachment.html