[oslc-core] TRS spec cutoffEvent property

[Joe Ross]

Good summary, Jim. I agree with your wording to clarify characteristics
that base set paging must have if it is unstable.

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311


Date: Wed, 15 May 2013 11:12:20 -0400
From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
To: oslc-core at open-services.net
Subject: Re: [oslc-core] TRS spec cutoffEvent property
Message-ID:

<OF7B0CCF5F.DE696FFC-ON85257B6C.005330C2-85257B6C.00538799 at ca.ibm.com>
Content-Type: text/plain; charset="us-ascii"

I had a brief side email conversation with Joe Ross and John Arwe
off-list.  We'd like to bring it back to this mailing list.  I've
summaried below.

---Jim

John asked me whether I thought the TRS spec required stable paging.

==============

Jim replied to John:

I confess that I don't understand what anyone means by 'stable paging'
with sufficient precision to answer one way or the other.  (And I've been
out-of-the-loop with the LQE WG discussions about paging strategies). The
current wording in the spec does not go into details of base paging per
se.

But let me give an example of one kind of paging that would not work:

At t1 the resource set has 4 resources A, B, C, D in its base. The server
pages the base into 2 pages with a max of 2 resources per page, say. The
pages are the resources p1 and p2.

p1 - has resources A, B
p2 - has resources C, D

A client that reads pages p1 and p2 after t1 will correctly determine that
the resource set has 4 resources.

At time t2, resource B is deleted from the resource set, and a
corresponding change event is added to the TRS's change log. The server
decides to rejig its existing pages, and delete B from p1, and shift C
from p2 to p1 (to preserve the 2 resources per page).

p1 - has resources A, C
p2 - has resources D

A client that reads pages p1 and p2 after t2 will correctly determine that
the resource set has 3 resources (A, C, D).

The problematic case is a client that starts reading the base before t2
but does not complete it until after t2.

A client that reads p1 before t2 and p2 after t2 would infer that the
resource set includes A, B, and D.  Processing the change log will kick
out B.  So this client will incorrectly conclude the set contains 2
resources, A and D.

The problem is clearly caused by this server mucking with how its base is
paged - and gets burned by moving the listing for C between pages. So
there are some plausible-looking strategies for paging the base that won't
cut it.

==================

Joe then replied to Jim:

I agree the type of unstable paging that you describe would be a problem.
We implemented unstable paging in such a way that items are never missed
but they can appear again in subsequent pages if they are modified during
the paging operation. The next page URL contains information to allow the
server to determine that the next page should start with C instead of D.

Perhaps the TRS spec should be reworded to say that the base set should be
implemented in such a way that a client paging through it will not miss
any entries that existed in the base set prior to the time of the
cutoffEvent.

==================

Jim then replied to Joe:

I agree. There should be additional words in the spec explaining the
essential properties of base paging. I suggest adding a para like this
after the para "Because of the highly dynamic nature of ...":

When a Base is broken into pages, the Client will discover and retrieve
Base page resources to determine the Resources in the Base. A Client MUST
retrieve all the page resources of the Base. A Client MAY retrieve the
Base page resources in any order, including retrieving some Base page
resources in parallel. A Client retrieves the Base page resources at its
own pace, and MAY retrieve any of the Base page resources more than once.
If the Server allows the representation of Base page resources to vary
over time, the Server MUST ensure that the set of Resources a Client would
infer as members is necessarily an approximation of the Resource Set
which, when corrected by Change Events after the Base's cutoff event,
yields the correct set of member Resources in the Resource Set.

===================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130515/1455bac6/attachment-0001.html
>

------------------------------

Subject: Digest Footer

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


------------------------------

End of Oslc-Core Digest, Vol 40, Issue 8
****************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130515/10d55b7b/attachment-0003.html>