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

[Darran Lofthouse]

I am also in favour of retaining some checks, in the past before these 
checks were added some of these leaks would be enough to bring down a 
production server.

Doesn't some of this fit into some for of developer mode switch that Max 
has asked for a couple of times?

Regards,
Darran Lofthouse.


On 10/19/2011 02:55 PM, Jaikiran Pai wrote:
> I agree that there should be a way to easily disable this. The only real
> reason why I am in favour of this simple check/cleanup is to ensure that
> some rogue application (which doesn't handle transactions correctly)
> doesn't end up breaking/affecting some other (well-written) application
> deployed on the same instance.
>
> -Jaikiran
> On Wednesday 19 October 2011 07:22 PM, Andrig Miller wrote:
>> 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
>>
>> ------------------------------------------------------------------------
>>
>>      *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
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev