[
https://issues.apache.org/jira/browse/JENA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991232#comment-12991232
]
Andy Seaborne commented on JENA-41:
-----------------------------------
Paolo wrote in [email protected]
> Would the "journaled file access" approach you have suggested be a
> solution for avoiding long reads forbidding/delaying writes?
It's one of the things you can do. It's a form of transactions, yet, for
read-access it retains the current performance model of TDB.
It allows reading and writing at the same time, up until the point the writes
need to be committed. At that point, optionally, write the changes to disk as
a journal log, also needed if the amount of change is very large (see a related
discussion on the dev list), then take a lock to get exclusive access to the
dataset. Write changes (with the opportunity to do write ordering for improved
performance), then release the exclusive lock.
In this scheme, a slow writer does not lock out readers, and readers do not
lock out the application writing changes. There is still an exclusive window
but it is shorter and not dependent on unhelpfully slow write clients.
If the journal log is persistent, then recovery from crashes during the commit
stage is a natural addition. A non-persistent journal is only useful for
speed, and given the journal can be written and read in an efficient style, I
would not have thought it would be hugely useful.
Alternatives include optimistic concurrency based scheme but the possibility of
clients needing to repeat actions is likely to be a burden so there would need
to be a much bigger advantage to outweigh the complexity.
Andy
> Different policy for concurrency access in TDB supporting a single writer and
> multiple readers
> ----------------------------------------------------------------------------------------------
>
> Key: JENA-41
> URL: https://issues.apache.org/jira/browse/JENA-41
> Project: Jena
> Issue Type: New Feature
> Components: Fuseki, TDB
> Reporter: Paolo Castagna
>
> 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] http://markmail.org/message/jnqm6pn32df4wgte
> [2] http://openjena.org/wiki/TDB/JavaAPI#Concurrency
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
