[
https://issues.apache.org/jira/browse/JENA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055721#comment-15055721
]
ASF GitHub Bot commented on JENA-1085:
--------------------------------------
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/108#discussion_r47478383
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java
---
@@ -55,21 +51,15 @@
private final DatasetPrefixStorage prefixes = new
DatasetPrefixStorageInMemory();
+ /** This lock imposes the multiple-reader and single-writer policy of
transactions */
private final Lock writeLock = new LockMRPlusSW();
- private Lock writeLock() {
- return writeLock;
- }
-
- private final ReentrantReadWriteLock commitLock = new
ReentrantReadWriteLock(true);
-
/**
- * Commits must be atomic, and because a thread that is committing
alters the various indexes one after another, we
- * lock out {@link #begin(ReadWrite)} while {@link #commit()} is
executing.
+ * Transaction lifecycle operations must be atomi, especially begin
and commit where
--- End diff --
OK, I'll simplify but the lock isn't just for commit. It is taken once at
the start and once at the finish of each transaction. The code used to have an
assumption about how quad/triple index.end() worked. Plug in other impls and it
may not be true. The lock now makes any index action over the indexes
thread-safe. The cost is the lock being taken on abort and in read-end. For
abort, we can assume does not matter too much (frequent aborts are a sign of
something in the application being wrong. Taking the lock in read-end is safe;
we'll be able to assess whether it is a significant cost by comparing with the
experiment on a non-transaction implementation.
> Review transaction finishes for DatasetGraphInMemory
> ----------------------------------------------------
>
> Key: JENA-1085
> URL: https://issues.apache.org/jira/browse/JENA-1085
> Project: Apache Jena
> Issue Type: Task
> Components: ARQ
> Affects Versions: Jena 3.0.1
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> This JIRA is for a review of the transaction finishing code.
> Some of the code works because of the nature of specific implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
