Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
MIME-Version: 1.0
In-Reply-To: <556EC74A.5040306@apache.org>
References: 
 <CAFU-9w9pHsmpRdgrAdFkxC9gv_o0a2xWKqRuzY-NtHNQTKjZOA@mail.gmail.com>
	<556DB6D3.4080602@apache.org>
	<CAFU-9w_7rhc8kTND0fcZcVbOn6iy3j=5_JrJTmnYYyFfhbh+=A@mail.gmail.com>
	<556EC74A.5040306@apache.org>
Date: Wed, 3 Jun 2015 15:18:22 +0300
Message-ID: 
 <CADBOR75XyaapPfuvLzUCaE1YrfL6Up+qFvufdu=4Pm0gQMHz8Q@mail.gmail.com>
Subject: Re: Tomcat DBCP 8.0.18 issue
From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YbRjtC6?= <denixx.baykin@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=f46d0444e9391fdf7305179c0e32

--f46d0444e9391fdf7305179c0e32
Content-Type: text/plain; charset=UTF-8

Mark, big thanks for a quick historical review, it was very intreresting!
I was thinking that tomcat-jdbc is something new, but wasn't sure about
project maintenance.

2015-06-03 12:22 GMT+03:00 Mark Thomas <markt@apache.org>:

> On 03/06/2015 07:24, Tweak Ronaldo wrote:
> > Thanks Mark, yes I have mixed together Tomcat JDBC 8 and DBCP 7, my bad.
> > Although I don't understand why Tomcat JDBC don't use DBCP as default
> > solution for connections pooling.
>
> Tomcat does - and always has - used Commons DBCP for connection pooling
> by default.
>
> We do package rename Commons DBCP to avoid conflicts for web
> applications that package it in WEB-INF/lib and we have changed how we
> have done that repackaging over the years but the source code remains
> unchanged from which ever release version / tag / svn revision we select
> to pull in.
>
>
> What follows is a short(ish) history of Commons DBCP and tomcat-jdbc
> which attempts to explain why Tomcat ended up shipping two connection
> pools.
>
> Commons DBCP 1 has very poor performance in highly concurrent
> environments. Things improved during the 1.x series but really didn't
> improve much above 'awful'.
>
> As users started to run Tomcat on machines with increasing numbers of
> cores, the performance issues with DBCP 1 started to have a noticeable
> impact for some web applications. Something needed to be done to address
> the performance issues in concurrent environments.
>
> There were two options:
> a) fix DBCP (essentially this meant a major re-write for Commons Pool)
> b) implement a new connection pool
>
> My preference was for a) although I had little time to do any work along
> those lines. Keep in mind that my preference for a) is likely to have
> coloured my view of the history of this.
>
> Filip's preference was for b). He also felt that there was room to
> further improve performance by removing the overhead inherent in:
> i)  Commons DBCP being built on Commons Pool
>     (a single module could be more tightly / efficiently integrated)
> ii) Commons DBCP aiming to fully follow the JDBC specs
>     (making some of the behaviours optional reduced overhead for
>      users that didn't want/need them)
>
> Filip therefore wrote tomcat-jdbc. He tried to release it several times
> without success. Apache releases need 3 +1 votes and there simply wasn't
> the interest in this component from the other Tomcat developers (this
> was one of my concerns with this approach).
>
> In order to get it released, tomcat-jdbc was bundled with Tomcat from
> 7.0.19 onwards (July 2011) but it was never configured to be the default.
>
> Filip's focus at work moved away from Tomcat development in 2012. He
> does pop back from time to time (mainly to fix issues with tomcat-jdbc)
> but it is fair to say that - at the moment - issues in tomcat-jdbc are
> not being resolved in a timely manner.
>
> Around the same time tomcat-jdbc was bundled with Tomcat, I (and others
> from Commons) started on Commons Pool 2 and Commons DBCP 2. Pool 2 was
> finally released in 2013 and DBCP 2 in 2014 (Tomcat 8 always used DBCP 2
> and had been depending on snapshot versions for some time before that).
>
> Commons Pool 2 and Commons DBCP 2 continue to be maintained by the
> Commons community (there was a Pool 2.4.1 release just last week) and I
> aim to keep Tomcat's copy of DBCP 2 (and Pool 2) up to date.
>
> Generally, bugs reported against Commons DBCP2 and Commons Pool 2 are
> addressed in a timely manner.
>
> tomcat-jdbc provided (and continues to provide) a simple solution for
> those Tomcat 6 and Tomcat 7 users that needed better performance under
> concurrent loads. Tomcat 8 and onwards users have DBCP 2 so there is
> less need for tomcat-jdbc for those users.
>
> Hope this helps explain how we got to where we are.
>
> As I typed this, I started to wonder if we should even ship tomcat-jdbc
> with Tomcat 9. I'll start a discussion along those lines on the dev list.
>
> mark
>
> >
> > 2015-06-02 16:59 GMT+03:00 Mark Thomas <markt@apache.org>:
> >
> >> On 01/06/2015 14:22, Tweak Ronaldo wrote:
> >>> Hello guys,
> >>
> >> Assuming you don't want to limit your question to men only, you would be
> >> better to use of of the following greetings:
> >> Hello,
> >> Hello all,
> >> Hello folks,
> >>
> >> etc.
> >>
> >>> we have migrated to Tomcat DBCP 8.0.18 from 7.0.37 recently and
> >>> faced the following issue:
> >>> after database restart (Postgres), our application wasn't been able to
> >>> restore connectivity to DB, all connections were closed and every time,
> >>> after failed attempt to execute some SQL statement, returned back to
> >> pool.
> >>> Pool is configured with all tests (on borrow, on return, on connect,
> >> while
> >>> idle) disabled. Pool configuration is the same for 8.0.18 and 7.0.37.
> >>> While using 7.0.37 DBCP is able to restore from DB restart, because
> >>> PoolableConnection class performs explicit check if underlying SQL
> >>> connection is closed:
> >>>
> >>>      public synchronized void close() throws SQLException {
> >>>         if (_closed) {
> >>>             // already closed
> >>>             return;
> >>>         }
> >>>
> >>>         boolean isUnderlyingConectionClosed;
> >>>         try {
> >>>             isUnderlyingConectionClosed = _conn.isClosed();
> >>>         } catch (SQLException e) {
> >>>             try {
> >>>                 _pool.invalidateObject(this); // XXX should be guarded
> to
> >>> happen at most once
> >>>             } catch(IllegalStateException ise) {
> >>>                 // pool is closed, so close the connection
> >>>                 passivate();
> >>>                 getInnermostDelegate().close();
> >>>             } catch (Exception ie) {
> >>>                 // DO NOTHING the original exception will be rethrown
> >>>             }
> >>>             throw (SQLException) new SQLException("Cannot close
> >> connection
> >>> (isClosed check failed)").initCause(e);
> >>>         }
> >>>        ...
> >>>
> >>> My question is: why this check was removed and how can one get the same
> >>> behaviour (of 7.0.37) using 8.0.18 (not using on borrow, on return,
> while
> >>> idle validations, which are SQL queries)? I see that there is a
> property
> >> in
> >>> pool configuration which allows user to provide custom Validator,
> though
> >> I
> >>> don't want to go this way because DBCP configuration is performed by
> 3rd
> >>> party library and we don't have direct access to it.
> >>
> >> The check to which you refer was not removed. It is still present in the
> >> code base and - as far as I can tell from a quick look at svn - never
> >> been removed.
> >>
> >> DBCP has no support for a custom validator. You appear to have confused
> >> something else with Tomcat's port of Commons DBCP (the Tomcat JDBC pool
> >> perhaps?).
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

--f46d0444e9391fdf7305179c0e32--