[
https://issues.apache.org/jira/browse/JENA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271551#comment-13271551
]
Dave Reynolds commented on JENA-244:
------------------------------------
Thanks for the clear and detailed analysis.
I agree that the lock acquisition strategy probably needs to move up, at least
to hasNext and possibly up to prepare itself. I also agree that the iterator
closing needs to reviewed, doesn't sound right.
I'm less convinced about moving prepare calls up the query level. Any deadlock
you can provoke via ARQ you could also provoke via straight API calls so it
would still need fixing at the engine level anyway. It seems preferable if ARQ
doesn't need to take any special actions when querying an InfGraph.
This is probably one I should take on but I can't do that in the immediate
future. Is your work around of pre-emptively called prepare() sufficient for
your application?
Dave
> Deadlock during SPARQL execution on an inference model
> ------------------------------------------------------
>
> Key: JENA-244
> URL: https://issues.apache.org/jira/browse/JENA-244
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Reporter: Stephen Owens
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
