Hi

> It probably is. As far as I am aware the connection pool in Jaybird 2.2 should work correctly if used standalone (but as the issue reported by Stefan indicates, that might not be right)...

While it is true, that our code runs inside a tomcat instance (started by a servlet listener), it is a pure java application, not using the container in any way. If we had the time, we had already modified our application not to be started by tomcat but to start tomcat embedded instead...
We already start tomcat without connectors and configure them at runtime.

So I think of our application as a standalone application. The use of tomcats database pools is not possible, as we will shortly remove tomcat from the biggest part of the picture.

> ... 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. ...

Ok, now I understand that decision.

> 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).

As mentioned earlier, I definitely preferred the FBWrappingDataSource because of that feature and we use PreparedStatements ONLY and we call "connection.prepareStatement" often more than 1000 times a second...
So is there any other pool who can make use of statement pooling?


Does anyone here on the list have any experience with one of the mentioned pools in respect to

Regards,
Steffen