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? Is that something SPARQL 1.2 could improve? 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 > >
