jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Is JDBC persistence manager supported by jackrabbit?
Date Thu, 01 Sep 2005 15:35:05 GMT
Marcel Reutegger wrote:
> 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...

Yes, it does. Thanks a lot.

It also means though, that XML PM is not for production use by design - in it 
current state. Note to that effect would be appropriate in the Javadoc, I think.


View raw message