> Kiyoko Takanabe wrote:
>
> There is only one JDBCContentStore for the whole system (by default) and
the
> current implementation has only one database connection for that store.
That
> connection is shared over all clients.
> There can be a performance problem if your documents are large and your
clients
> are on a slow connection.
>
> The problem with using a pool is that you need a database with distributed
> transaction support because there are multiple stores that must be rolled
back at
> the same time (node + revision + content + ...).
> In JDBC2.0 this XADataSource support is optional.
> Remy has just volentiered to complete support for this XADataSource.
>
> There are improvement that we (or you) can do for JDBC 2.0
> - Use a pool for the read actions
> - Combine the structure & content store into one and then we can use a
normal pool
> (from DataSource or the jakarta-commons pool) for write actions as well.
I'm +1 for combining them, but it raises some code management problems.
Historically, they were separate since the content store wasn't working at
all until recently.
Remy
