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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
