On 01/03/2021 08:52, Martynas Jusevičius wrote:
Thanks for the explanation.
But an implementation is also free to reject a second request, per the
specification?
So for SPARQL 1.1 a write strategy portable across implementations
should be sequential, i.e. one request has to complete before the next
one is executed?
Strange question - why do you ask?
FWIW: By the spec, a server can reject any request just because it feels
like it.
Fuseki doesn't; it does not return 202 either.
Are you saying that some servers reject (true) concurrent writes?
Is that something SPARQL 1.2 could improve?
"atomic" is what HTTP defines.
It is impossible to prescribe much more and still cover all possible cases.
Andy
On Sun, Feb 28, 2021 at 12:47 PM Andy Seaborne <a...@apache.org> wrote:
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
