> I think you have 2 way to resolve this problem:
> 1) Catch this exception and, if needed, get a new connection from the
> datasource
> 2) (The best solution and the most adopted) Get a connection for each
> transaction/set of queries, make your queries and close the connection
> at the end.

I suspect that the reason is different. Pool keeps connections open
for "infinite" period of time (unless idle timeout is specified, but
let's forget it for now). However, it seems that your server is
configured to drop open socket if no activity is happening during XXX
seconds (this is network configuration of the operating system, not
Firebird). After that pool still believes that connection is open
(because it did not close it), however socket is no longer valid. Pool
returns connection to the application, but the application cannot do
anything with it, returns it back. Connection is still believed to be
valid. This will happen until the pool is restarted.

You have to check if DBCP provides a possibility to validate a
connection before returning it to the application. JayBird 1.5 pool
implementation has so called "pingStatement" and "pingInterval" -
simple "SELECT CAST(1 as INTEGER) FROM rdb$database" is executed each
"pingInterval" seconds. There must be something similar in DBCP too.

Roman