> I am not sure that is true - can you show me where this is
> documented?

See maxStatements property of the connection pool and the JDBC specification
regarding the statement pooling.

> Most JDBC drivers that provide this functionality do not do it by
> default - for example, Oracle's thin JDBC requires an explicit and
> proprietary call to instigate PS caching. I am referring to global
> caching across opening and closing connections - not just within an
> open/close.

I think I do not understand you. Prepared statement is created by a
connection object. Therefore, its lifetime is limited to the lifetime of
that object. When connection is physically closed, prepared statement is
released.

If you mean DataSource.getConnection() and corresponding Connection.close(),
yes, you are right. Pool should have this feature. But from my point of view
it was noticed too late and I will not delay 1.5.0 release by introducing
this feature. I will rather release 1.5.1 beta/rc right after the 1.5.0
release.

> The JDBC driver must explicitly hold the PS indexed by the uniqueness of
> the SQL string - avoiding reparsing and rebuilding.

JDBC driver does not parse the SQL statement (except the escaped syntax),
the statement is passed "as is" to the server. From the point of view
"SELECT foo, bar FROM bla" and "select foo , bar from bla" are two different
statements.

> Where did Roman go?

I'm back. :)

Roman