Hi, I'm again raising the old issue (see for example [1] and [2]) of using a connection pool in the database persistence managers. Previously those arguments have been countered but the issue is becoming more pressing with the fine grained locking feature and recently I think we've been moving towards inventing our own DataSource abstraction with the ConnectionRecoveryManager class. I'd like to take these two developments together and to again suggest that we switch to using connection pools in Jackrabbit.
The main benefits from using a connection pool would be: 1) Removing the database connection bottleneck. With fine grained locking and even before that with large binaries in the database we are facing the problem that the single database connection used by a persistence manager becomes a bottleneck for serving multiple concurrent clients. Currently a single client that performs a large import or retrieves a large binary will block all uncached access to an entire workspace. This is a major performance and usability issue. 2) Simplified connection recovery code. Most connection pools will automatically discard broken connections, removing the need for explicit reconnect logic in Jackrabbit. There's lots of complex "trials--" code in Jackrabbit that we could just drop if we used a connection pool. 3) Simplified prepared statement caching. Many connection pools are able to automatically cache prepared statements, removing the need for explicit statement caching in Jackrabbit. 4) Familiar connection model. Many potential contributors are quite familiar with the J2EE best practices for using database connections, so adopting them in Jackrabbit would lower the barrier of entry for new contributions. The familiar connection model will also make many database administrators (who're typically the ones who need to manage Jackrabbit instances in production) happier. WDYT? [1] http://markmail.org/message/oz376dss2whtmrww [2] http://markmail.org/message/ai72otqjqmgapfyp BR, Jukka Zitting
