W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: Resolution for ISSUE-37

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 01 Oct 2010 08:57:13 +0100
Message-ID: <4CA59459.40802@epimorphics.com>
To: Alexandre Passant <alexandre.passant@deri.org>
CC: Steve Harris <steve.harris@garlik.com>, Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>


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.

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.
]]

	Andy
Received on Friday, 1 October 2010 07:59:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT