Subject | Re: [Firebird-Java] connection pool |
---|---|
Author | Mark Rotteveel |
Post date | 2014-02-24T10:33:23Z |
On Sat, 22 Feb 2014 13:54:18 -0500, Ray Holme <rholme@...>
wrote:
use it.
should work correctly if used standalone (but as the issue reported by
Stefan indicates, that might not be right). However the implementation
violates a number of requirements and expectations set forth by the JDBC
specification (for example the pool is part of the ConnectionPoolDataSource
implementation FBConnectionPoolDataSource, but a ConnectionPoolDataSourc`
is not supposed to hold a connection pool; it is supposed to be a factory
for connections held in a connection pool, the subsequent behavior on close
of a connection results in incorrect behavior when it is used the way a
ConnectionPoolDataSource is supposed to be used.
However this behavior is fundamentally part of the implementation in
org.firebirdsql.pool which makes it hard to fix without breaking other
parts left and right. Hence the decision to add a barebones implementation
of ConnectionPoolDataSource, XADataSource and DataSource to
org.firebirdsql.ds and to remove org.firebirdsql.pool entirely.
As writing a correct and performant connection pool is rather hard, I
think that is better to leave that to projects where that is the main focus
(eg BoneCP, c3p0, others I forget right now).
Mark
wrote:
> I sure hope there is a general connection pool manager forTomcat has its built in connection pool, but you need to configure it to
> Tomcat/Apache.
use it.
> I wrote one years ago (pre dawn) and put it on the blocksIt probably is. As far as I am aware the connection pool in Jaybird 2.2
> as I was told the JDBC connection pool was implemented and simply stupid
> to re-write (suggestion from the Firebird folks that I know and
> respect).
>
> Hopefully this is not the same pool manager that Mark was talking about.
should work correctly if used standalone (but as the issue reported by
Stefan indicates, that might not be right). However the implementation
violates a number of requirements and expectations set forth by the JDBC
specification (for example the pool is part of the ConnectionPoolDataSource
implementation FBConnectionPoolDataSource, but a ConnectionPoolDataSourc`
is not supposed to hold a connection pool; it is supposed to be a factory
for connections held in a connection pool, the subsequent behavior on close
of a connection results in incorrect behavior when it is used the way a
ConnectionPoolDataSource is supposed to be used.
However this behavior is fundamentally part of the implementation in
org.firebirdsql.pool which makes it hard to fix without breaking other
parts left and right. Hence the decision to add a barebones implementation
of ConnectionPoolDataSource, XADataSource and DataSource to
org.firebirdsql.ds and to remove org.firebirdsql.pool entirely.
As writing a correct and performant connection pool is rather hard, I
think that is better to leave that to projects where that is the main focus
(eg BoneCP, c3p0, others I forget right now).
Mark