This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/jena-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new b3b3c5d Updated site from main
(5e6627980a972ea8dc66220f227ddd86d5d0053f)
b3b3c5d is described below
commit b3b3c5dd253366e04f66aad5dad0704d1b28553d
Author: jenkins <[email protected]>
AuthorDate: Sun Apr 18 09:18:08 2021 +0000
Updated site from main (5e6627980a972ea8dc66220f227ddd86d5d0053f)
---
content/documentation/index.xml | 3 +-
content/documentation/notes/concurrency-howto.html | 55 ++++------------------
content/index.xml | 3 +-
content/sitemap.xml | 4 +-
4 files changed, 14 insertions(+), 51 deletions(-)
diff --git a/content/documentation/index.xml b/content/documentation/index.xml
index 43b87ef..8217a5e 100644
--- a/content/documentation/index.xml
+++ b/content/documentation/index.xml
@@ -513,8 +513,7 @@ On Linux / Mac
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://jena.apache.org/documentation/notes/concurrency-howto.html</guid>
- <description>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 intact but
would not give an application consistent access to the RDF graph. It would also
limit the throughput of multi-threaded applications on multiprocessor machines
where true concurrency can lead to a reduction in response time.
-For example, supposed an application wishes to read the name and age of a
person from model.</description>
+ <description>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 intact but would not give an application consistent
access to the RDF graph. It would also limit the throughput of multi-threaded
applications on multiprocessor machines w [...]
</item>
<item>
diff --git a/content/documentation/notes/concurrency-howto.html
b/content/documentation/notes/concurrency-howto.html
index 9fdc9e7..1fc2c8d 100644
--- a/content/documentation/notes/concurrency-howto.html
+++ b/content/documentation/notes/concurrency-howto.html
@@ -175,7 +175,14 @@
</div>
<h1 class="title">Concurrent access to Models</h1>
- <p>Applications need to be aware of the concurrency issues in access
+ <i>
+All datasets provide transactions.
+This is the preferred way to
+handle concurrenct access to data.
+</i>
+<br/>
+<br/>
+<p>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
intact but would not give an application consistent access to the
@@ -199,12 +206,8 @@ the application burden is not high.</p>
<li>Multiple applications accessing the same persistent model
(typically, a database).</li>
</ul>
-<p>Transactions are provided by persistent models: see
-the <a href="/documentation/tdb/tdb_transactions.html">TDB documentation</a>
-and the <a href="/documentation/sdb/index.html">SDB documentation</a>
-and for details.</p>
<p>This note describes the support for same-JVM, multi-threaded
-applications.</p>
+applications using in-memory Jena Models.</p>
<h2 id="locks">Locks</h2>
<p>Locks provide critical section support for managing the
interactions of multiple threads in the same JVM. Jena provides
@@ -225,46 +228,8 @@ be other application threads reading the model
concurrently.</p>
<h2 id="iterators">Iterators</h2>
<p>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.</p>
-<h2 id="sparql-query">SPARQL Query</h2>
-<p>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.</p>
-<p>Outline:</p>
-<pre><code> 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() ; }
-</code></pre>
-<p>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.</p>
-<p>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.</p>
-<h2 id="compatibility">Compatibility</h2>
-<p>The actually interface is called <code>Lock</code> and has implementations
-including <code>LockMRSW</code>.</p>
-<p>For compatibility with previous versions of Jena, there is a class
-<code>ModelLock</code>.</p>
</div>
diff --git a/content/index.xml b/content/index.xml
index 8902299..725192e 100644
--- a/content/index.xml
+++ b/content/index.xml
@@ -564,8 +564,7 @@ On Linux / Mac
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://jena.apache.org/documentation/notes/concurrency-howto.html</guid>
- <description>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 intact but
would not give an application consistent access to the RDF graph. It would also
limit the throughput of multi-threaded applications on multiprocessor machines
where true concurrency can lead to a reduction in response time.
-For example, supposed an application wishes to read the name and age of a
person from model.</description>
+ <description>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 intact but would not give an application consistent
access to the RDF graph. It would also limit the throughput of multi-threaded
applications on multiprocessor machines w [...]
</item>
<item>
diff --git a/content/sitemap.xml b/content/sitemap.xml
index c190b56..c121b65 100644
--- a/content/sitemap.xml
+++ b/content/sitemap.xml
@@ -264,7 +264,7 @@
<url>
<loc>https://jena.apache.org/documentation/notes/concurrency-howto.html</loc>
- <lastmod>2020-02-28T13:09:12+01:00</lastmod>
+ <lastmod>2021-04-17T18:19:33+01:00</lastmod>
</url>
<url>
@@ -309,7 +309,7 @@
<url>
<loc>https://jena.apache.org/documentation.html</loc>
- <lastmod>2021-03-29T09:48:59+01:00</lastmod>
+ <lastmod>2021-04-17T18:19:33+01:00</lastmod>
</url>
<url>
