OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] [change request #128] cache invalidation due to perform*Interaction()


Title: Message
Andre,
 
Can you elaborate on why initCookie implies synchronization at a MUST level on the Consumer end?
 
Eilon
-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Tuesday, February 11, 2003 3:55 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [change request #128] cache invalidation due to p erform*Interaction()

Our initCookie() already implies a synchronization, on a per-user basis, at the consumer. As we therefore already have a consumer side serialization requirement, the perUser "perform[Blocking]Interaction() expires cached markup" case should be supportable, even in load balanced consumers at the page level.
 
But we should look into relaxing the expires requirement for the forAll (user scope) case (a SHOULD for the all user scope?) and possibly also allowing small time based inconsistencies in the perUser caching scope case. Like initCookie() and our performBlockingInteraction() page blocking semantics, we may then end up saying very little about real end users who may have multiple consumer side sessions...
 
regards,
Andre
-----Original Message-----
From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
Sent: 11 February 2003 05:41
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [change request #128] cache invalidation due to perform*Interaction()

I completely agree.
 
One example brought in the F2F was that of a load-balanced (a.k.a., clustered) Consumer, who - if we enforce an invalidation algorithm - MUST communicate to the other servers in the clusters in order to discard an invalidated cached, and handle it consistently in a concurrent environment (race conditions etc.).
 
Hopefully nothing else in the spec mandates intra-cluster communication at the Consumer level, and if that's the case, we probably want to deal with it in a well-thought-of fashion, as Mike suggested.
 
Eilon
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Sunday, February 09, 2003 9:16 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [change request #128] cache invalidation due to perform*Interaction()

My preference is that we stick with the decision we made in the November
F2F which recognized the complexities of invalidation caching and
deferred any specification of such until after 1.0.  Our current model
is based on a well understood and time tested caching model.
 Invalidation, though ultimately an important developers tools for
achieving optimal performance needs our time and energy to specify a
complete and flexible solution.  Our current solution is satisfactory.
 As cache maintanence is controlled by the consumer, consumers are free
to provide the semantics you describe in this change control and market
themselves as a better solution without our specification saying
anything about invalidation.  Portlets running on systems without this
feature merely receive "stale" data/content -- something that is
inherent in caching systems/portals/consumers anyway. 

Some reasons for deferring:
We should be concerned about implementability by the consumer.  Though
some consumers will deal with the complexities of implementing
invalidation based caching, we shouldn't require all consumers to do so.
 Such consumers, however, will likely find it easy/convenient to
implement our current caching semantics.  Ultimately, work should be
done to allow consumers to support caching levels.  Adding
wording/function as you are suggesting to our current specification
prevents such behavior.

We should be concerned about extensibility in the future to provide a
richer solution.  Though, all or nothing invalidation is both convenient
for the developer and affords an easy specification, our experience
shows that this ultimately must be coupled with a more flexible
invalidation model where the portlet can explicitly control each piece
of content to be invalidated.  Though more work, [invalidation] caching
is about optimization and optimization in general involves more work/a
deeper knowledge to the true nature of interactions.
    -Mike-

Rich Thompson wrote:

>Document: Spec
>Section: 6.2.1.2
>Page/Line: 39/10
>Requested by: Rich Thompson
>Old text: [insert new paragraph]
>Proposed text: Consumers invoking either performInteraction() or
>performBlockingInteraction() MUST treat any markup cached for the
>equivalent MarkupParams (i.e. the MarkupParms structure passed to the
>invocation updated with any honored newMode or newWindowState requests and
>any returned navigationalState) as if the expiry time had elapsed unless
>the response includes a new CacheControl structure indicating the cached
>markup is still valid.
>
>Reasoning: I had promised last Wednesday to post a proposal for how
>interaction processing impacts cached markup.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC