[
https://issues.apache.org/jira/browse/JENA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271599#comment-13271599
]
Stephen Owens commented on JENA-244:
------------------------------------
Dave,
Good point about API calls triggering the same behaviour. You're right that
there shouldn't be special action from ARQ, the graph should be able to protect
itself.
Once I've tried the work around I'll let you know. I'm just trying to create a
reproducible test case that shows the behaviour so I can verify.
Thanks for the pointer on the forward chaining, I don't see why that wouldn't
work in terms of the rules I need. I think that this is the relevant statement
that makes this a preferable alternative for consistency in execution?
"Once the preparation phase is complete the inference graph will act as if it
were the union of all the statements in the original model together with all
the statements in the internal deductions graph generated by the rule firings.
All queries will see all of these statements and will be of similar speed to
normal model accesses. It is possible to separately access the original raw
data and the set of deduced statements if required, see above."
Given that it is the prepare call that is responsible for both forward and
backward chaining additions (I think) then would I still need to ensure that I
call prepare before any queries are submitted? Or because forward chaining adds
rules to the internal deductions graph is the lock strategy different enough
that this issue wouldn't be a problem?
> 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
