Hi, [Branching the thread]
On 8/21/07, Thomas Mueller <[EMAIL PROTECTED]> wrote: > My question is: should we support multiple connections in the > persistence manager? > > If using multiple connections really does improve performance / > scalability of Jackrabbit, I think we should think about it (long > term, for NGP). Using multiple connections does not mean using > databases. Multiple connections can be supported with file based > persistence managers as well (or course the transaction isolation > level needs to be defined). > > First we need proof that using multiple connections does help. > > Some feedback was along the line 'Jackrabbit must use DataSources / > Pooled Connections because... it is better than using one > Connection!'. I like to understand why and in what cases it is better. The main argument I can see for multiple connections (or more precisely a DataSource with a connection pool) within the database persistence managers is to avoid the synchronization on the PreparedStatements. Especially now that the locking in SharedItemStateManager has become more fine-grained, there is a chance that the synchronization within the persistence manager becomes a bottleneck for certain access patterns. Also, there is a valid argument that a statements from a single Connection should not be used concurrently from multiple threads. Furthermore, from a code clarity point of view I would personally prefer a solution that didn't require explicit synchronization. BR, Jukka Zitting
