Andy, thank you very much, it’s ver kind of you. Things are a lot clearer now
fps > Le 5 sept. 2015 à 18:21, Andy Seaborne <[email protected]> a écrit : > > On 05/09/15 16:20, François-Paul Servant wrote: >> trying to understand how to write a sparql servlet that handles read-write >> operations… > > The code in Fuseki is available to look at. > >> >> I read >> - https://jena.apache.org/documentation/notes/concurrency-howto.html >> - http://jena.apache.org/documentation/tdb/tdb_transactions.html >> (though not working specifically with TDB) >> - and >> http://stackoverflow.com/questions/18968971/is-it-possible-to-concurrently-write-to-the-same-dataset-file-but-to-different-n >> >> Not sure to understand everything, correct me if I’m wrong, and TIA if you >> can answer some of these questions: >> >> - if within an application, a model can be updated, then any call to jena >> (or at least, any one that iterates over something) must be inside some kind >> of lock. > > Yes > >> - for memory models, including datasets built around memory models, the only >> option is model.enterCriticalSection/leaveCriticalSection > > No - DatasetGraphWithLock is another option, then use begin/end. > > You can look at the code in Fuseki. > > SPARQL_Query.execute. > >> - with TDB, use dataset.begin/dataset.end > > Yes > >> - your code must not enter a locking section if you’re already in one. It >> looks that this means that you probably must have some kind of one central, >> unique entry point in your code where you lock/unlock -- hmm, doesn’t seem >> easy > > Not sure what is behind the question - locks are java's > ReentrantReadWriteLock (transactions are not - that would be a nest > transaction which is not supported) > >> - in a sparql query over a dataset with memory named graphs, if updates are >> possible, you must lock all the graphs (Dataset.listNames to get the names >> of the graphs, loop over them to enterCriticalSection) > > No - the Dataset must be locked. Dataset.getLock() > > Locking the models does not help protect the dataset in the general case. > >> - if a sparql query doens’t include updates, it is better to just take a >> READ lock > > Yes > >> - so a big question is: how do you known if a query contains updates or not > > SPARQL Query and SPARQL Update are different languages precisely for this > case. This isn't SQL! > > You can't parse SPARQL Update with the query parser - disjoint keywords. > >> - if a sparql query doens’t include updates, is it enough to take a READ >> lock only on the graphs included in the query? > > No - one lock on the Datasets > >> - (necessary only if the answer of previous one is “yes”) you get the graphs >> in a query with the union of getGraphURIs and getNamedGraphURIs” ? > >> >> that’s all for the moment, thank you. >> >> Best Regards, >> >> fps >> >
