- From: Alexandre Passant <alexandre.passant@deri.org>
- Date: Sun, 3 Oct 2010 11:09:50 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: Steve Harris <steve.harris@garlik.com>, Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 1 Oct 2010, at 08:57, Andy Seaborne wrote: > > > On 30/09/10 23:24, Alexandre Passant wrote: >> >> On 30 Sep 2010, at 08:04, Steve Harris wrote: >> >>> On 2010-09-29, at 18:55, Lee Feigenbaum wrote: >>> >>>> On 9/29/2010 1:42 PM, Alexandre Passant wrote: >>>>> Hi all, >>>>> >>>>> I'm checking current issues in the Update doc, and see that ISSUE-37 is closed. >>>>> >>>>> RESOLVED: close ISSUE-37 by adding a note to Update mentioning possible feedback effects >>>>> + >>>>> ACTION: paul to add a note on possible feedback effects of federated queries in update (ACTION-289) >>>>> >>>>> Do Paul or anyone remind what we meant by "feedback effects" here ? >>>>> Seems to relate to atomicity ? >>>> >>>> The use case in question involved using SERVICE in the WHERE clause of an update operation, I believe. >>> >>> That's correct. Different levels of atomicity could lead different stores to return different results. >> >> Here's what I added >> >> Initial text: >> >> Each request<strong>should</strong> be treated atomically by a SPARQL 1.1 Update service. Any resulting concurrency issues will be a matter for each implementation to consider according to its own architecture. >> >> Added: >> >> However, using SERVICE in the WHERE clause of an Update request may lead to unexpected results in terms of atomicity, leading to different stores to return different results.</p> > > I see two issues here: > > Firstly, and the one we discussed IIRC, it's the case of SERVICE coming back, directly or indirectly, to the originating update request graph store (is it inside or outside any "transaction", what can it see of changes?) > > Secondly, which I don't think is ISSUE-37 directly, if there are two SERVICE calls in a update request, then they may see different states of the world, for example if they ask the same pattern on the same remote service endpoint they may get different answers because an update at the far end has occurred. > Indeed, makes sense. > The added text works quite well for that but may I suggest dropping the comment about different stores. The same store, in the same state, may lead to different outcomes at different times. > > [[ > However, using SERVICE in the WHERE clause of an Update request does not guarantee atomicity. > ]] Thanks, updated. Alex. > > Andy -- Dr. Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Sunday, 3 October 2010 10:10:25 UTC