incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: [jena-dev] TDB concurrency
Date Fri, 25 Feb 2011 08:17:45 GMT
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:
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.


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
jena-users-subscribe AT

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.

View raw message