Relaxation of transaction requirements

[kjetilk]

Why?

SPARQL 1.1 Update discusses atomicity, and also notes that "Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success."

The Solid project has encountered a problem around this in the case where isolation could not be maintained.

My interpretation of this is the following (based in part on the discussion within the Solid project but also with @afs ): Consider the case where two concurrent users do a DELETE-INSERT operation, then if the endpoint does not maintain isolation, the success status will not be helpful in determining if isolation was breached. Thus, for this use case, it seems to be an expectation that atomicity and isolation is maintained.

It is not necessarily a requirement everyone should meet (though, I personally prefer to use conditional requests).

I think we should discuss relaxing this requirement, and instead communicate a conflict.

Previous work

@timbl has a Design Issue where he strongly advocates that a 409 Conflict should be sent at the protocol level in this case.

Proposed solution

Add a "conflict" operation result to SPARQL Update, that SPARQL implementations that does not maintain ACID can/should/must use to indicate conflict.

Add 409 Conflict to the SPARQL Protocol to be used whenever the underlying implementation indicates a conflict.

Considerations for backward compatibility

For services currently supporting ACID, there should be no changes. Clients that have previously relied on that the servers supports ACID, will need to add logic to support conflicts, including detecting 409, update and reschedule their writes.

[kasei]

Clients that have previously relied on that the servers supports ACID, will need to add logic to support conflicts, including detecting 409, update and reschedule their writes.

As http clients, wouldn’t they already need to detect errors such as this?

[kjetilk]

Clients that have previously relied on that the servers supports ACID, will need to add logic to support conflicts, including detecting 409, update and reschedule their writes.

As http clients, wouldn’t they already need to detect errors such as this?

Yes, they would, but they wouldn't necessarily know what to do with them?

[afs]

A protocol service may use other 4XX or 5XX HTTP response codes for other failure conditions, as per HTTP.

It could be useful to describe some of the cases like 409 that arise and when they are appropriate. That sounds like it could be in a "best practice guide" (and using conditional requests and ...) because it is explaining how HTTP applies and then isn't tied to an WG/spec cycle.

[lisp]

to do this would be to conflate protocol and application logic.
a more reliable approach is to manage metadata as an aspect of the state of the store rather than to try to divine it from the incidental content.
the cited "solid" discussion worries, in that it reads as if the proposal intends to rely on contingent state of the store to indicate that no change has happened.
this may succeed iff the application model represents the temporal properties explicitly.
modelling requirements on that order should not be incorporated into the language.

[kjetilk]

a more reliable approach is to manage metadata as an aspect of the state of the store rather than to try to divine it from the incidental content.

Yes, it most certainly is. However, not all implementations are necessarily willing or able to manage the metadata in the store to allow for this, and the suggestion amounts to not requiring them too, but still have a fallback mechanism that can be used in lieu of such a system.

[lisp]

what is the intended outcome if a sequence of intervening operations causes the store to return back to a state which conceals any pertinent change?

[namedgraph]

And what happens if concurrent write requests are submitted to the server? Either SPARQL updates or Graph Store Protocol PUT/POST/DELETE? I can't see where the SPARQL specs consider this.

[TallTed]

SPARQL 1.0 did not consider transaction isolation nor other ACID elements at all; SPARQL 1.1 gives these only minimal consideration or mention (e.g., silent success for DELETE operations that may have multiple reasons for having no effect). LDP didn't do much better (though I and some others tried).

You have to reach back to SQL and ODBC/JDBC/ADO.NET/OLE DB for full consideration.