[jira] [Commented] (JENA-1861) Query not thread safe

["Andy Seaborne (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090066#comment-17090066 ] 

Andy Seaborne commented on JENA-1861:
-------------------------------------

There are two different exceptions:

# {{Query.setResultVars}}, when concurrent updates within {{Query}} interfere.
# Concurrent calls of {{OptimizerStd.transformExprConstantFolding}} causing concurrent calls of {{ExprDigest}}.

(1) can be fixed by making the actual work of {{setResultVars}} synchronized. This works (= the test case, together with the fix for (2) below, runs without problems for many minutes).

A better solution is to do the {{setResultVars}} as parsing finishes (and equivalent build steps in jena-querybuilder). This also works except it breaks some tests in {{TestSyntaxTransform}}. The internal details of the query state are different even if the transformed query is equivalent to the expected query, just not perfectly {{.equals}}. This is either untidiness in {{QueryTransformOps}} (leaves different internal state in the transformed query even if this state no longer matters) or excessive detail in the query compare.

(2) is fixed by using {{CacheFactory.createOneSlotCache()}}, not two member variables {{lastSeen}} and {{lastCalc}}, which aren't manged safely.

> Query not thread safe
> ---------------------
>
>                 Key: JENA-1861
>                 URL: https://issues.apache.org/jira/browse/JENA-1861
>             Project: Apache Jena
>          Issue Type: Question
>          Components: ARQ
>    Affects Versions: Jena 3.14.0
>            Reporter: Claus Stadler
>            Assignee: Andy Seaborne
>            Priority: Major
>
> Executing the same query object on different RDFConnections is not thread safe:
> I ran into very misleading "NPE in NodeFactory.createLiteral" exceptions when computing SHA256 sums in parallel on different connections backed by different datasets/models using the SAME query object.
> I identified the cause as due to a race condition due to the digestCache used in [ExprDigest|https://github.com/apache/jena/blob/d95b7d295cebaeb2ea41029f4ee7781be94e5e85/jena-arq/src/main/java/org/apache/jena/sparql/expr/ExprDigest.java#L33]
> My first question is: Are Query objects - or rather expressions - supposed to carry execution state or is this rather a bug?
> I know that some parts of the Query object, such as result vars, are only initialized on request which makes use of the same Query object in different threads fragile to begin with.
> So my other question is: Given a Query object, is Jena supposed to allow for 'fully initializing' it, such that its execution using Jena's provided facilities (models, datasets, etc) is guaranteed to not modify its state?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)