[
https://issues.apache.org/jira/browse/JENA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054985#comment-15054985
]
ASF GitHub Bot commented on JENA-1085:
--------------------------------------
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/108#discussion_r47445013
--- 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 --
This comment is a bit confusing. How about:
```
We have a lock for committing because transaction lifecycle operations must
be atomic, especially {@link Transactional#begin} and {@link
Transactional#commit}, for which the global state of the (possibly multiple)
indexes may be read or written one after another.
```
> 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)
