Re: Connection in JDBCContentStore?

[Dirk Verbeeck <di...@pandora.be>]

Kiyoko Takanabe wrote:

> Hi, Remy.
>
> Sorry, my question is poor explanation.
> I get potentially the wrong idea.
> I'd like to check again for your unswer.
>
> my questions are following:
>
> 1)  If there are access of the one client to slidestore,
>      create a JDBCContentStore instance respect to the client?
>
> 2)  Will JDBCContentStore be created with respect to each client ?
>       that is multiple JDBCContentStore instances are created?
>
> 3)  If terms of 2) has not been established,
>      even a single JDBCContentStore instance respect to multiple clients
>      (i.e. a single connection),
>      are there no problems on performance?
>
> regards.

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.

If you have clients with slow connections we can also improve performance by
writing the document first to disk and then sending it to the client, by doing
this we free the database connection for the next request.

If you are doing performance tests please send us the results, we can then use
them to tune the system.


Dirk

Re: Connection in JDBCContentStore?

[Remy Maucherat <re...@apache.org>]

> 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