Hi, > > The only alternative I can see is to implement our own connection > pool, but imho that's unnecessarily re-inventing the wheel. > > I just wanted to know what exactly is required additionally (direct > and indirect dependencies). I'm not saying it's a problem.
Ok, I misunderstood, sorry. > > Well...also the cached PreparedStatements from e.g. the BundlePMs > have been removed. > > Some connection pools do cache PreparedStatement, but we should > probably verify that it actually works in our case. To find it out > what JDBC method are called, you could use the H2 database and add > ;TRACE_LEVEL_FILE=3 to the database URL. Thanks for the hint. I'll try it. The commons-DBCP library has functionality for caching PreparedStatements. I can imagine that the caching is more "dynamic" than with the current approach in the trunk because commons-DBCP can dynamically adjust the pool sizes of the Connection and PreparedStatement pools, which probably depends on the usage pattern. Furthermore, a component that requests a connection prepares a statement and then does the same again might get an other connection the second time for which the statement has not been pooled yet. It would indeed be interesting to see how the caching performs in the automated tests. Have you any other test scenario's in mind? Best regards, Martijn
