Skip to content
Browse files
JENA-957: Revise doc for concurrency - model only
  • Loading branch information
afs committed Apr 18, 2021
1 parent 0af4fc9 commit 5e6627980a972ea8dc66220f227ddd86d5d0053f
Showing 1 changed file with 10 additions and 53 deletions.
@@ -2,6 +2,14 @@
title: Concurrent access to Models

All datasets provide transactions.
This is the preferred way to
handle concurrenct access to data.

Applications need to be aware of the concurrency issues in access
Jena models. API operations are not thread safe by default. Thread
safety would simple ensure that the model data-structures remained
@@ -29,13 +37,8 @@ There are two main cases:
- Multiple applications accessing the same persistent model
(typically, a database).

Transactions are provided by persistent models: see
the [TDB documentation](/documentation/tdb/tdb_transactions.html)
and the [SDB documentation](/documentation/sdb/index.html)
and for details.

This note describes the support for same-JVM, multi-threaded
applications using in-memory Jena Models.

## Locks

@@ -62,51 +65,5 @@ be other application threads reading the model concurrently.

Care must be taken with iterators: unless otherwise stated, all
iterators must be assumed to be iterating over the data-structures
in the model or graph implementation itself.  It is not possible to
in the model or graph implementation itself. It is not possible to
safely pass these out of critical sections.

## SPARQL Query

SPARQL query results are iterators and no different from other
iterators in Jena for concurrency purposes. The default query
engine does not give thread safety and the normal requirements on
an application to ensure MRSW access in the presence of iterators
applies. Note that Jena's query mechanism is itself multi-threaded.
If the application is single threaded, no extra work is necessary.
If the application is multi-threaded, queries should be executed
with a read lock.


Model model = ... ;
String queryString = " .... " ;
Query query = QueryFactory.create(queryString) ;
model.enterCriticalSection(Lock.READ) ;
try {
try(QueryExecution qexec = QueryExecutionFactory.create(query, model)) {
ResultSet results = qexec.execSelect() ;
for ( ; results.hasNext() ; )
QuerySolution soln = results.nextSolution() ;
RDFNode x = soln.get("..var name..") ;
} finally { model.leaveCriticalSection() ; }

Updates to the model should not be performed inside the read-only
section. For database-backed models, the application can use a
transaction. For in-memory models, the application should collect
the changes together during the query processing then making all
the changes holding a write lock.

Jena Locks do not provide lock promotion - an application can not
start a "write" critical section while holding a "read" lock
because this can lead to deadlock.

## Compatibility

The actually interface is called `Lock` and has implementations
including `LockMRSW`.

For compatibility with previous versions of Jena, there is a class

0 comments on commit 5e66279

Please sign in to comment.