I forgot one issue:
JCR-1148 - may happen with both ISMLocking implementations. the fix is IMO quite
easy and low risk: move synchronization of mod count into copy().
regards
marcel
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
