jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Przemyslaw Pakulski <przemo.pakul...@cognifide.com>
Subject Re: DP Persistence manager implementation
Date Fri, 03 Feb 2006 00:18:29 GMT
Marcel Reutegger <[EMAIL PROTECTED]> wrote:

> this is not quite true. the actual store operation on the persistence manager is synchronized.
however most of the write calls from different threads to the JCR api in jackrabbit will not
block each other because those changes are made in a private transient scope. only the final
save or commit of the transaction is serialized. that's only one part of the whole write process

But in fact in real application most of business method ends with either 
save, checkin or commit, and in consequence concurrent calls of this 
methods will block each other and wait for storing modified data.
We are using versioning feature intensively, and we have performance 
problems mainly with write operations. Additionally we notice big 
performance degradation when we switch to SimpleDBPersistenceManager 
with MySQL or other db using network communications. So it looks like 
overall performance depends much on PM implementation because all 
save/checkin operations wait for PM until he finish all his work.
One solution to avoid blocking write operations could be special 
thread/s responsible for flushing data to PM, but i don't think so that 
Jackrabbit uses asynchronous processing.

> even if such a persistence manager allows concurrent writes, it is still the responsibility
of the caller to ensure consistency. in our case that's the SharedItemStateManager. And that's
the place where transactions are currently serialized, but only on commit.
> If concurrent write performance should become a real issue that's where we first have
to deal with it.

If there exists any singleton component on top of PM, which is 
reponsible for serializing all saves, checkins or transactions then 
naturally using connection pools doesn't help, but maybe it means that 
Jackrabbit is not designed to work effectively in multithreaded environment.

Even if usage of connection pool is not reasonable in current design, I 
think it is worth to consider JDBC batch updates instead of single 
updates to gain better DBPM performance.

Przemo Pakulski

View raw message