[
https://issues.apache.org/jira/browse/JENA-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235405#comment-14235405
]
Andy Seaborne commented on JENA-824:
------------------------------------
I prefer that parsing produces an object that can be passed around and used
multithreaded. Later modification operations need to act at their own risk.
{{Query.setResultVars}} violates that, as it not called by parsing as far as I
can see. It should be idempotent so it can be called cheaply "just in case".
"seal" need not be a explicit operation, it can be part of the (documented)
contract.
Compatibility is quite important and even Jena3 isn't, to me, sufficient to put
in a required .seal() - it affects a lot of code.
> Concurrent usage of query causes NPE
> ------------------------------------
>
> Key: JENA-824
> URL: https://issues.apache.org/jira/browse/JENA-824
> Project: Apache Jena
> Issue Type: Bug
> Reporter: Kristian Rosenvold
>
> Callin gQueryFactory.parse and then handling the Query off to multiple
> threads can/will cause the error show in the stacktrace.
> As long as setResultVars is called on the Query before handing off to
> threads, it seems to be safe.
> Pull request is coming on this.
> java.lang.NullPointerException
> at com.hp.hpl.jena.sparql.core.Var.varNames(Var.java:193)
> at com.hp.hpl.jena.query.Query.getResultVars(Query.java:369)
> at
> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.asResultSet(QueryExecutionBase.java:470)
> at
> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:533)
> at com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
