I meant to improve the interoperability at least, if not the concurrency. BTW, how long is the queue of blocked requests permitted to grow?
On Mon, Mar 1, 2021 at 9:52 AM Martynas Jusevičius <marty...@atomgraph.com> 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? > > 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 > > >
