Concurrent writes to memory graphs?

[Holger Knublauch <ho...@knublauch.com>]

I guess many Jena users have run into the issue that you cannot write to a memory graph if any query iterators are open (or rather: the iterators throw an exception as soon as a write happens).

Are there any strong technical obstacles that make it impossible to implement a Jena Graph that doesn't have this limitation? What are the trade-offs? Does anyone know of an in-memory RDF store in Java that allows concurrent writes? This could then be plugged behind Jena's Graph interface.

Thanks
Holger

Re: Concurrent writes to memory graphs?

[Andy Seaborne <an...@apache.org>]

On 21/02/12 05:00, Holger Knublauch wrote:
> I guess many Jena users have run into the issue that you cannot write
> to a memory graph if any query iterators are open (or rather: the
> iterators throw an exception as soon as a write happens).
>
> Are there any strong technical obstacles that make it impossible to
> implement a Jena Graph that doesn't have this limitation? What are
> the trade-offs? Does anyone know of an in-memory RDF store in Java
> that allows concurrent writes? This could then be plugged behind
> Jena's Graph interface.

No.
Space.  Implementation costs.
Yes.
(what semantics do you want for the query?  It does or does not see 
changes as it goes along?)

The Graph API is an abstraction that can be implemented with different 
non-functional characteristics.

If you want write-while-read AND consistency either behind the scenes do 
what you have to do to avoid concurrency (e.g. have a grah and a record 
of adds and deletes).  Or use a transactional system and use two 
transactions ...

TDB runs in-memory as well as disk.  It's not designed for performance 
but all that means is that it's never been tested for such.  Every thing 
works - the test suite uses an in-memory dataset where possible because 
disk-based is very, very slow.

(if you don't want consistency just use concurrent hash maps for indexes 
- but if you have > 1 index, they may not be consistent)

	Andy

>
> Thanks Holger
>