[jena-site] branch jena957 updated (9261333 -> 713d247)

[an...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

andy pushed a change to branch jena957
in repository https://gitbox.apache.org/repos/asf/jena-site.git.


 discard 9261333  JENA-957: Revise doc for concurrency - model only
     new 713d247  JENA-957: Revise doc for concurrency - model only

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (9261333)
            \
             N -- N -- N   refs/heads/jena957 (713d247)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 source/documentation/notes/concurrency-howto.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[jena-site] 01/01: JENA-957: Revise doc for concurrency - model only

[an...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

andy pushed a commit to branch jena957
in repository https://gitbox.apache.org/repos/asf/jena-site.git

commit 713d247a5abd4370b6803e06c936e6b8215f0264
Author: Andy Seaborne <an...@apache.org>
AuthorDate: Sat Apr 17 18:19:33 2021 +0100

    JENA-957: Revise doc for concurrency - model only
---
 source/documentation/notes/concurrency-howto.md | 63 ++++---------------------
 1 file changed, 10 insertions(+), 53 deletions(-)

diff --git a/source/documentation/notes/concurrency-howto.md b/source/documentation/notes/concurrency-howto.md
index 2d36908..9fb2ca8 100644
--- a/source/documentation/notes/concurrency-howto.md
+++ b/source/documentation/notes/concurrency-howto.md
@@ -2,6 +2,14 @@
 title: Concurrent access to Models
 ---
 
+<i>
+All datasets provide transactions. 
+This is the preferred way to
+handle concurrenct access to data.
+</i>
+<br/>
+<br/>
+
 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.
+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.
-
-Outline:
-
-      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
-`ModelLock`.