[
https://issues.apache.org/jira/browse/JENA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009191#comment-13009191
]
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
TransactionManager.transactionCommit(DatasetGraph)
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 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
> Attachments: Transaction.java, TransactionHandle.java,
> TransactionHandler.java, TransactionManager.java,
> TransactionManagerBase.java, TransactionalDatasetGraph.java
>
>
> 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
