On Sat, 22 Feb 2014 16:13:15 +0000, "Steffen Heil (Mailinglisten)"
<lists@...> wrote:

>> For Jaybird 2.2 I fixed some concurrency bugs in this class, but due to
>> other fundamental flaws in the implementation of the connection pool in
>> the org.firebirdsql.pool classes, I have decided to deprecate the

entire

>> package ...
>
> So there will be no pool implementation inside jaybird anymore?

That is right, from Jaybird 3.0 there will no longer be a connection pool
implementation.

> What is the correct way to obtain a connection that can be used in a

pool?

> (I am considering using one of the mentioned packages or writing my own,
> as I am only using a very limited function set and I already have a
> wrapping class...)

The easiest way is to use a third party library. I'd strongly suggest not
to roll your own. If you do want to roll your own, you could use
org.firebirdsql.ds.FBConnectionPoolDataSource to obtain a PooledConnection
implementation. A PooledConnection is the handle to a single physical
database connection. It exposes a getConnection() method that creates a
logical java.sql.Connection (and closes any previously created logical
connection if still open!). It is almost, but not entirely a normal
connection. One of the differences is that a call to close() will close the
logical connection (and dependent objects), and signal the event
listener(s), but it will not close the actual physical connection.

You keep these PooledConnection objects in your connection pool and
register a ConnectionEventListener on it to listen for its lifecycle
events. When a connection request come in, you find an available
PooledConnection and call its 'getConnection' to get a new logical
connection, the PooledConnection then needs to be marked as 'checked out'.
When the close event is signaled, the connection pool knows the
PooledConnection is available again for the next request and marks it as
available.

> On the other hand, I always preferred the build-in pool, since I thought
> that would be the only way to get the improvements from statement

caching

> and all that...

Most third party connection pools also have a form of statement pooling (I
know for sure c3p0 and BoneCP have it). However, I haven't tested if this
works OK with Jaybird. I believe currently Statement.isPoolable() always
returns false, but I don't know if that is actually used by these
connection pools.

> Are these features deprecated as well or are they usable by any

connection?

For now they are. I am considering to move statement pooling to the actual
connections, but that might be more trouble than it is worth.

> Altogether: What is the recommended way to get a connection and how to
> configure it?

Inside an applicationserver: either use the Jaybird JCA implementation, or
use the internal connection pool in combination with
org.firebirdsql.ds.FBConnectionPoolDataSource or drivermanager obtained
connections.

Separate applications: use FBSimpleDataSource (without pooling), or use a
third party connection pool.

Mark