incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (JIRA)" <>
Subject [jira] [Commented] (JENA-41) Different policy for concurrency access in TDB supporting a single writer and multiple readers
Date Mon, 21 Mar 2011 16:16:05 GMT


Andy Seaborne commented on JENA-41:

I've been wondering if the DatasetGraph interface itself is the interface to transactions.
 It does behave like a connection to the database anyway.

A call to:
  TransactionManager.transactionBegin(DatasetGraph, READ or WRITE) 
returns another DatasetGraph that can be used and

This doesn't couple transactions directly to threads although I'm still assuming that each
transaction is itself single threaded operations (no parallel writes inside a transaction).
 The returned DatasetGraph can have all the machinery for transaction control and can be passed
to library code that is transaction-unaware.

For isolation levels, I think the only one that makes sense in the RDF world is SERIALIZABLE
because although the weaker levels guard the database, units of the triple aren't the applications
view of the world where a row in a table might be a single application concept.

> Different policy for concurrency access in TDB supporting a single writer and multiple
> ----------------------------------------------------------------------------------------------
>                 Key: JENA-41
>                 URL:
>             Project: Jena
>          Issue Type: New Feature
>          Components: Fuseki, TDB
>            Reporter: Paolo Castagna
>         Attachments:,,,,,
> As a follow up to a discussion about "Concurrent updates in TDB" [1] on the jena-users
mailing list, I am creating this as a new feature request.
> Currently TDB requires developers to use a Multiple Reader or Single Writer (MRSW) locking
policy for concurrency access [2]. Not doing this could cause data corruptions.
> The MRSW is indeed a MR xor SW (i.e. while a writer has a lock, no readers are allowed
and, similarly, if a reader has a lock, no writes are possible).
> This works fine in most of the situation, but there might be problems in presence of
long writes or long reads.
> It has been suggested that a "journaled file access" could be used to solve the issue
regarding a long write blocking reads.
>  [1]
>  [2]

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message