bkirsch and i have had a few conversations about how
jackrabbit
effectively serializes database writes, which to our supreme
elite
haxxor ears sounds like a performance bottleneck. the issue
came up
again yesterday on the jackrabbit list, and now an issue has
been
filed to looking at more ways to possibly do concurrent
writes. i'm
glad to see some thought being put into this area.
Fine grained locking in SharedItemStateManager
----------------------------------------------
Key: JCR-314
URL: http://i
ssues.apache.org/jira/browse/JCR-314
Project: Jackrabbit
Type: Improvement
Components: core
Reporter: Marcel Reutegger
Priority: Minor
The SharedItemStateManager (SISM) currently uses a simple
read-write
lock to ensure data consistency. Store operations to the
PersistenceManager (PM) are effectively serialized.
We should think about more sophisticated locking to allow
concurrent
writes on the PM.
One possible approach:
If a transaction is currently storing data in a PM a second
transaction may check if the set of changes does not
intersect with
the first transaction. If that is the case it can safely
store its
data in the PM.
This fine grained locking must also be respected when
reading from the
SISM. A read request for an item that is currently being
stored must
be blocked until the store is finished.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atl
assian.com/software/jira
_______________________________________________
Cosmo mailing list
Cosmo osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo
|