I think it may be best to take a long look at the various
*ItemStateManager classes in a holistic manner. It appears that these
classes introduce a lot of the locking and synchronization issues (as
would be expected from such a key group of classes). The movement
towards using more fine grained locking makes a lot of sense, but I
think we still have a mix of locking and explicit method level
synchronization. In addition, it seems that we do not really look at
transaction isolation levels to determine locking strategies. In some
instances dirty reads and writes may be acceptable and using
configurable tx isolations levels could allow the end consumer to
tweak the system for their application environment. I would love to
see us move towards having the cache and persistence layers separated
and management of the internal hidden from things such as shared item
state manager. In my experience most if not all the issues we have
seen in our production systems (in terms of where threads lock, and I
have tons of thread dumps showing this under load) occur within
SharedItemStateManager and ItemManager. As we see these issues pile up
I think it behooves us to take a long hard look at these core classes
and ensure that we are going down the right path.
-paddy
On Dec 18, 2007, at 2:23 AM, Marcel Reutegger wrote:
hi all,
there are a number of synchronization issues I would like to resolve
for the 1.4 release. some of them are related to using the new
FineGrainedISMLocking but most of them are general synchronization
issues that may happen with both DefaultISMLocking and
FineGrainedISMLocking, though more visible with the latter.
JCR-1271 - this issue happens with both ISMLocking implementations.
The cache in LocalItemStateManager is accessed at the same time by
the thread using the session and by the thread that notifies
ItemState changes. JCR-935 happens for the same reason.
JCR-1272 - this issue happens with both ISMLocking implementations.
instead of adding synchronization, I suggest to operate on possibly
stale states. see patch.
JCR-1274 - this is only an issue with the FineGrainedISMLocking.
when using the DefaultISMLocking the exclusive write lock prevents
any reading from the cache. this is different when using
FineGrainedISMLocking. This locking strategy allows reading from the
cache while a change is processed. Hence it may happen that reading
from and writing to the cache happens concurrently. One solution may
be to completely synchronize the ItemStateCache in
SharedItemStateManager. This however reduces concurrency on the
cache for reading threads. Another solution I can think of is to
allow the ISMLocking implementation to wrap the ItemStateCache if
necessary. DefaultISMLocking would simply return the cache as is,
while FineGrainedISMLocking would have to wrap the cache into a
synchronized variant.
comments are welcome.
regards
marcel
