Edgar Poce wrote:
Vadim Gritsenko wrote:
PS Wiki page has incorrect statement:
XML PersistenceManager
* Write operations are synchronized
AFAICS, XML PM (unnecessarily) syncronizes all calls, including load()
and exist() calls.
Why incorrect? maybe incomplete...
The current implementation of the XML PM serializes all calls to
store(), load() and exists(). This is because it operates on a
non-transactional store (a FileSystem implementation). The FileSystem
interface does not prevent dirty reads by its definition. Writing
changes to a FileSystem that involves multiple files therefore *must*
block reads, otherwise other sessions might see changes that are not yet
completely committed.
The crucial point is PersistenceManager.store() which states:
Atomically saves the given set of changes.
I agree, that's not extremely descriptive ;) but it actually describes
in one sentence what the PM has to guarantee.
> Does it mean FileSystem interface considered to be
single threaded?
I don't think so
No, the FileSystem interface does not specify any constraints on
concurrency. However each implementation will certainly contain some
synchronization in its internals. But that's something you don't have to
bother about when using a FileSystem.
> Does not make much sense, though...
I agree. I think that the concurrency issue was handled first at the
SHISM level, then it was moved to the PM, and then back to the SHISM
(see http://issues.apache.org/jira/browse/JCR-164). Those synchronized
modifiers seem to be there because the PM contract is not very clear
yet, at least for me :(.
basically what applies to a PM is also true for the
SharedItemStateManager (SHISM). But things are a bit more complex
because it involves an additional guarantee:
ItemState instances issued by the SHISM must be unique. The SHISM must
not return two distinct ItemState objects for the same ItemId!
But in the end, it's again the same contract as for a PM. Store
operations must be atomic.
The easist implementation is to use a read-write lock, which is
currently used in SHISM.
This is certainly not the perfect solution. e.g. two ChangeLogs which do
not intersect could be stored concurrently (if the PM is able to manage
this). Similarly reading ItemStates that do not conflict with a
ChangeLog that is currently stored should not be blocked.
hope this clarifies things a bit...
regards
marcel
