Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <4316BC28.4090005@gmx.net>
Date: Thu, 01 Sep 2005 10:30:32 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Is JDBC persistence manager supported by jackrabbit?
References: <20050716042756.66476.qmail@web32702.mail.mud.yahoo.com>
 <42D907A2.8070408@gmail.com> <df4m4f$s8s$1@sea.gmane.org>
 <43167705.1030608@gmail.com>
In-Reply-To: <43167705.1030608@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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