On Fri, Jul 12, 2013 at 5:14 PM, Minto van der Sluis <[email protected]> wrote:
> Op 12-7-2013 15:59, Reto Bachmann-Gmür schreef:
>
>>> - Is there someway I can shortcut things to ensure using fastlane? Since
>>> most of my queries involve multiple graphs. We are having serious
>>> performance problems that might be related to slow-lane. That is why I
>>> started messing around fuseki in the first place (to do some performance
>>> analysis to determine clerezza overhead).
>> You could send the query directly to the TcProvider. Using this method
>> you don't have security, probably not even after resolution of
>> CLEREZZA-801.
>>
>> Adding this possibility to TcManager would be a bit difficult as the
>> clients don't see the underlying TcProviders.
>>
>> What we could do is to have:
>>
>> public Object executeSparqlQuery(String query, UriRef
>> defaultGraphName, boolean forceFastlane)
>>
>> if forceFastlane is true the query is fastlaned to the provider of
>> defaultGraphName even if the query targets other graphs as well. A
>> slightly weird behaviour would occur if the provider of
>> defaultGraphName also provides a graph that is shadowed by another
>> provider with a higher weight. In this rare case you could access
>> graphs that are otherwise not accessible. But this seems to be a
>> seldom corner case.
> Might it also be possible to create a fastlane QueryEngine? Almost like
> JenaSparqlEngine but this time not wrapping TcManager in a dataset but
> instead using the dataset inside the TcProvider. Sort of like this:
>
> public class JenaFastlaneQueryEngine implements QueryEngine {
>
> //
> ------------------------------------------------------------------------
> // Implementing QueryEngine
> //
> ------------------------------------------------------------------------
>
> @Override
> public Object execute(TcManager tcManager, TripleCollection
> defaultGraph,
> final Query query) {
> // TODO: how to get tcProvider from TcManager?
> Dataset dataset;
> if (tcProvider instanceof JenaTcProvider) {
> // Jena provider use fastlane.
> dataset = JenaTcProvider.class.cast(tcProvider).getDataset();
> } else {
> // Not a jena provider revert to slowlane.
> dataset = new TcDataset(tcManager, defaultGraph);
> }
The issue is that a TcManager has typically more han one TcProvider.
Because the underlying providers are not exposed it is necessary to do
the routing in TcManager. This could of course be changed but I don't
see any advanage in your proposal.
I suiggest we first investigate and resolve the exception you got. And
then look at some optimization for the case a jena graph is wrapped
first by a facade.JenaGraph and then by a storage.JenaGraphAdaptor.
Also we can add the method to enforce the fastlane.
Cheers,
Reto
> ...
>
> Or maybe even wire the QueryEngine to a QueryableTcProvider sort of like
> this:
>
> ...
> @Override
> public Object execute(TcManager tcManager, TripleCollection
> defaultGraph,
> final Query query) {
> // TODO: how to get tcProvider from TcManager?
> if (tcProvider instanceof QueryableTcProvider) {
> return
> QueryableTcProvider.class.cast(tcProvider).executeSparqlQuery(...);
> }
> ...
>
> Just some thoughts.
>
> Regards,
>
> Minto
