On 01/03/2021 15:13, Martynas Jusevičius wrote:
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?
I ask because we have a client implementation and we want to have the
write strategy as general as possible, and not triplestore-dependent.
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.
But there must be a limit to how many write requests Fuseki can queue?
It isn't reading the request until inside the write transaction. So the
waiting cost is the lock space and connection which are small. I would
have though the server would run out of connections before it ran out of
space. (Fuseki sets the thread counts quite low specifically to be
defensive.)
Then SPARQL Updates are executed operation by operation, not reading the
whole request at once.
GSP writes are streamed to the dataset.
Are you saying that some servers reject (true) concurrent writes?
Yes, Dydra does that. James can probably expand on this.
Data imports from our system can produce large and overlapping GSP
write requests, but we cannot send them simultaneously if we want them
to succeed.
There are other reasons not to generate significant numbers of
concurrent updates, like not being a DOS attack.
Andy
