[
https://issues.apache.org/jira/browse/JENA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054343#comment-15054343
]
ASF GitHub Bot commented on JENA-1085:
--------------------------------------
Github user afs commented on the pull request:
https://github.com/apache/jena/pull/107#issuecomment-164159785
Revised pull request (entangled with changes at Apache).
The revision
* Puts the transaction finalization code inside the commit/abort code that
takes the system lock. This mean the lock is taken once at the finishing of a
transaction.
* Reorganises the code to a rigid pattern for operations.
* Renames `commitLock` as `systemLock`
* Uses `ReentrantLock`, not `ReentrantReadWriteLock` (only the write lock
was used; the implement of a `ReentrantReadWriteLock.WriteLock` and
`ReentrantLock` is much the same for our usage, just calls to the `sync`
object).
As well as code review, design review would be appreciated. Compared to
the original design, this makes `abort` take a lock and call `abort` on indexes
whereas previously it simply did nothing, knowing the index implementations
would cope. Because `abort` is a not a performance critical operation
(usually!), the symmetric and explicit calls to index operations makes things
clearer in my view.
> 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)
