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


Reply via email to