Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of castagna.lists@googlemail.com
 designates 74.125.82.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=QfelnbtGlaZSNkHmsQbWAd3JLITQhmV8XphQJaI9acX0PJzdI2rTrA/6oe8qzfXOyS
         4DftiXBLVN6SyNYjs7IOWNnmYsWbGnUSGti/k0YFmjEa6MlKyg2Nju6ctETTIidOOkrD
         7StAZsZUhD3nG97Gd79K17/Zb6vJWwP8nrw6A=
Message-ID: <4D6765A9.7040700@googlemail.com>
Date: Fri, 25 Feb 2011 08:17:45 +0000
From: Paolo Castagna <castagna.lists@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: jena-dev@yahoogroups.com
CC: jena-dev@incubator.apache.org
Subject: Re: [jena-dev] TDB concurrency
References: <AANLkTikiy3FZObg5459E5AVEHJr-VHabvHih-xKPECo6@mail.gmail.com>
In-Reply-To: <AANLkTikiy3FZObg5459E5AVEHJr-VHabvHih-xKPECo6@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Danny,
Dave and Damian have already answered your question.
In the past, I had those sort of doubts about MRSW myself.
A simple multi threaded test can help finding the answer.

For clarity, it's MR XOR SW.

It's an exclusive OR: if you are writing, nobody can read.
Therefore a long write would block access to readers.
Similarly, a long read would block any write too.

There is an issue (i.e. New Feature) for this:
https://issues.apache.org/jira/browse/JENA-41
We should discuss technical details there.

Andy proposed "journaled file access".

I'd like to help on this and try to do a prototype as a proof of concept.
However, I am not an expert on this (i.e. I've never wrote a journaled
file access system before) and it does not appear to be only a "small
matter of programming". ;-)

There are a lot of details which are not clear to me.

Damian's suggestion works perfectly for your.

Paolo

PS:
I know it's a pain, but we are trying to move the mailing
list to Apache. Please, subscribe by sending an email to:
jena-dev-subscribe AT incubator.apache.org
jena-users-subscribe AT incubator.apache.org

Danny Ayers wrote:
> on the wiki it says:
> [[
> TDB provides a Multiple Reader or Single Writer (MRSW) policy for
> concurrency access. Applications are expected to adhere to this policy
> - it is not automatically checked.
> 
> One gotcha is Java iterators. An iterator that is moving over the
> database is making read operations and no updates to the dataset are
> possible while an iterator is being used.
> ]]
> 
> I'd like to check I'm reading this correctly - is it that many readers
> can access the data concurrently but the (one and only) writer should
> have an exclusive lock - and that lock should block reading..?
> 
> The scenario I'm looking at will be TDB shared between Fuseki and
> programmatic access (a Turtle editor).
> 
> I've haven't yet really got a clue how I'll handle the sharing, so if
> anyone's got any code for a similar situation I'd be grateful for a
> pointer.
> 
> (Right now I've got the editing happening on a single memory model, so
> for the moment at least I can probably get away with access to TDB
> models through a read-(edit)-replace kind of cycle).
> 
> Cheers,
> Danny.
>