Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <50E74BCD.8000403@christopherschultz.net>
References: 
 <CAPw873vy+9kWMQiFPbnTX6g1FSQ8oTVhDJ3Zagp9UkUZ3d5qjw@mail.gmail.com>
	<50E73CEB.4090708@christopherschultz.net>
	<50E74901.3010101@pidster.com>
	<50E74BCD.8000403@christopherschultz.net>
Date: Fri, 4 Jan 2013 23:56:04 +0100
Message-ID: 
 <CAPw873vGqh09h1GBSPkSXL20_uPVUYPD9DU9H-QAzifg=VcFPg@mail.gmail.com>
Subject: Re: [jdbc-pool] Transaction left open by the connection validation
 mechanism ?
From: "Davoust, Pascal" <pascal.davoust@eptica.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc06f05d39a904d27e625f

--047d7bdc06f05d39a904d27e625f
Content-Type: text/plain; charset=ISO-8859-1

Indeed I was referring to the tomcat jdbc-pool code, not mine :-).

Now, I would suggest to consider that this problem is more common than you
could imagine at first sight. First because this is randomly occuring, but
frequently enough so that it shows up in quite a few areas.
A few examples where this problem occurred and was filed (but not analyzed
down to the root cause):

Spring DataSource Txn Mgr :
https://jira.springsource.org/browse/SPR-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

Hyperic :
https://jira.hyperic.com/browse/HHQ-5054

If I'm correct, then I suggest that the behavior is corrected by default,
not requiring additional configuration. Especially so that most people use
the provided sample and documentation, which enables the validation
mechanism. Or maybe do it the other way round, have a configuration key
which allows to disable the rollback after validation... One last way would
have been to test against the auto commit state of the connection to decide
whether a rollback was necessary, but I believe that the pool does not
maintain the connection state for performance reasons (unless an
interceptor is configured to do it) and therefore would be an even more
detrimental hit on performance since would require a round-trip to the db
server...

In any case, let me know if you need me to provide more details or to file
this problem into the bug tracking system!

Regards

Pascal

2013/1/4 Christopher Schultz <chris@christopherschultz.net>

> > I think Pascal is saying that the above snippet is in the Tomcat
> > JDBC code, not his.
>
> Whoops, I think you're right. That's a minor bug, but definitely one
> that should be fixed IMO.
>
> Also, if the validation query succeeds and the connection is in
> auto-commit mode, we may want to issue a rollback. I wouldn't want to
> do that without any additional configuration, though, because it would
> needlessly send ROLLBACK queries in many cases (such as other
> databases - MySQL doesn't get upset when I tried a simple, similar
> test - or when you don't intend to change the transaction isolation
> level, etc.).
>
> Perhaps a configuration directive like rollBackAfterValidationQuery or
> something?
>
> - -chris
>

--047d7bdc06f05d39a904d27e625f--