On 05/09/15 16:16, François-Paul Servant wrote:
Hi,
still wondering why I see such differences in performances, I asked myself
whether this is not related to the fact that my servlet doesn’t take care of
concurrency: all my test queries are read-only, but real code should take care
of it (and actually, this is one of the reasons why I was looking at fuseki:
not to have to worry about this kind of troubles).
Note that in my very first experiment, when I was looking at times on the
fuseki server side, I had started the fuseki server without the —update
options, cf
./fuseki-server --mem /ds
instead of
./fuseki-server --update --mem /ds
and times were not better.
You have also said your running in Tomcat but those commands run in Jetty.
--update does not change the internal transaction handling - it change
what is accessible. The simple way to provide "no update" is to not
have any update operations. SPARQL query and SPARQL update operate on
different endpoints; the Graph Store Protocol uses the methof type to
control access.
Anyway, I decided to try to add some minimal code in my servlet - I came to
several questions regarding the way to do it (that I’ll ask in another
message). For the moment, I just modified my doGetSparql method with:
See DatasetGraphWithLock
Dataset ds = getDataset(req);
if (ds.supportsTransactions()) {
ds.begin(ReadWrite.WRITE) ;
} else {
ds.getDefaultModel().enterCriticalSection(Lock.WRITE) ;
}
Different concurrency in the presence of update but your examples are
read-only.
try {
QueryExecution qexec = QueryExecutionFactory.create(query, ds);
...
} finally {
if (ds.supportsTransactions()) {
ds.end();
} else {
ds.getDefaultModel().leaveCriticalSection() ;
}
}
(clearly, as I’m using a memory model, what is used is the
“enterCriticalSection” mode. I don’t know how I could make it handle correctly
the case where there are named graphs in the dataset, but I leave that for my
next message)
fps
