On 26/02/2021 14:41, Martynas Jusevičius wrote:
Hi,
How does Fuseki handle concurrent write requests?
Serializably.
If we are talking about TDB or TIM, it MR+SW, "multiple reader AND
single writer" enforced so that if a second writer turns up, it waist
for the first to complete. Includes text indexing.
(Generally, not just RDF, this is quite common pattern nowadays.)
General datasets (mixed storage, rules)is MRSW "multiple reader OR
single writer".
Both SPARQL update and GSP?
Yes.
Say if there's an active POST to the graph store and another one is
received, what happens?
The second one waits.
There isn't any "read-committed" or other ways that phantom reads, or
skew happen. AKA count() only returns an answer that was right at a
point in time.
Fuseki does not expose read-commited-on-promotion which the machinery
supports. And that is the only weaker isolation form in TDB/TIM.
The only mention of concurrency in the SPARQL specs that I can find
says it's implementation-defined:
"Each request should be treated atomically by a SPARQL 1.1 Update
service. The term 'atomically' means that a single request will result
in either no effect or a complete effect, regardless of the number of
operations that may be present in the request. Any resulting
concurrency issues will be a matter for each implementation to
consider according to its own architecture. In particular, using the
SERVICE keyword in the WHERE clause of operations in an Update request
will usually result in a loss of atomicity."
https://www.w3.org/TR/sparql11-update/#updateServices
Martynas
