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] | [List Home]

Subject: RE: [wsrp-wsia] [change request #187] Cacheability and perform*Interaction

This distributed consumer use case sounds very much like the one I had
coming into wsrp and was one reason why I thought having to maintain
consumer side cookies for producer sessions was problematic.

As we do require consumers to return producer session cookies, does this not
imply consumer side shared state that can also be used to record if a
portlet has been acted on subsequent to some getMarkup? A simple timestamp
would do per portlet (kept with session cookie value for SOAP client stub
and used to suppress cached markup), as long as one is careful to set this
when transferring consumer (user) state between consumer side load balanced

So a layer of interaction management above caching (not full invalidation
caching) seems a quite feasible solution to me in the scenarios we planned
for in 1.0. Why should we require producers to pollute navigational state
(with large random numbers) when consumers could add the required
application specific semantics?


-----Original Message-----
From: Eilon Reshef [mailto:Eilon.Reshef@webcollage.com]
Sent: 28 February 2003 18:32
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [change request #187] Cacheability and
perform*In teraction


In a way, I think that Mike is suggesting that we cannot assert that the
user always gets an updated markup, but in reality this will be the case. 

For example, in a clustered environment, one portal server may be issuing a
performInteraction call and receive back a markup. Consequently, the user
would get back an updated markup. But when the user hits (for example) the
"refresh" button, the request may go to another portal server, who may have
an old copy of the markup in place, hence the markup would "revert" to the
old markup. Mike (if I understand correctly) has also suggested that some
portals may ignore the markup from a performInteraction call and hence the
issue may arise under simpler circumstances.

One may note that the Producer can always easily avoid this issue, by simply
adding a unique token (e.g., a random number) to the returned markup state
upon completing an interaction.

To *fully* address this issue (along the lines of the above example), it
seems that we need to add invalidation semantics (which we have agreed not

We may want to provide a partial resolution along the lines of the previous
correspondence by suggesting that the Consumer would use the returned markup
from performInteraction rather than any cached version, but the challenge is
phrasing the suggestion in a way that does not imply fully-blown cache

Explicitly stating that actions need to be routed to the Producer/portlet
may be helpful in this regard.


-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com] 
Sent: Friday, February 28, 2003 17:10
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [change request #187] Cacheability and perform*In

Michael Freedman wrote:
> But, Alan, an action isn't cacheable.  Why is there any ambiguity 
> about
> whether actions propogate to the portlet?  Are you concerned that 
> readers will get confused now that we have added the capability for an 
> action to be optimized by returning markup?  I would be surprised by 
> this, but if enough folks think action semantics are unclear a few words 
> stating that "actions aren't cacheable and hence portlets will always 
> receive them" should be sufficient.

This is not obvious from the spec. We need to say explicitly that 
portlets always recived actions regardless of any cached markup.

But the spec would be incomplete if it does not guarantee that the end 
user gets to see updated markup after an action. If not by Alan's 
proposal, how else do you propose to ensure this?


> As for clarifying how the Consumer manages the cache -- I personally
> think its clear enough however if folks think some clarifying words 
> should be added then fine as long as the clarifying words define the 
> semantics that have already been agreed on.  I.e. we currently define no 
> semantics for how an action impacts how a Consumer manages the cache. 
> I.e. the impacts of actions on how the consumer manages the cache is 
> exactly what we voted to defer to after 1.0.
>     -Mike-
> Kropp, Alan wrote:
>>An important objective of this change request is the point that 
>>actions must propagate to the portlet, regardless of the existence of 
>>unexpired cached content.  Is that not a requirement of the JSR?  
>>Would not its absence from WSRP be a serious problem for WSRP-JSR 
>>synchronization on interaction processing?
>>I fail to see how this somehow resurrects the invalidation question, 
>>but I'd gladly revisit the wording if folks think this is the 
>>implication.  It is definitely not my intent.  Read carefully, either 
>>my or Rich's text says absolutely nothing about the Producer telling 
>>the Consumer to invalidate its cache.  The text is entirely focused on 
>>directing how the Consumer manages the cache when processing an 
>>action.  I do not agree that the spec already gives clarity on this 
>>point, and feel its explicit mention, in the section on action 
>>processing, lends the clarity I feel is missing.
>>-----Original Message-----
>>From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
>>Sent: Thursday, February 27, 2003 11:01 AM
>>To: wsrp-wsia@lists.oasis-open.org
>>Subject: Re: [wsrp-wsia] [change request #187] Cacheability and 
>>I strongly object to this change request and ask that it be withdrawn.
>> We have already discussed and rejected twice now adding invalidation 
>>semantics in 1.0.  This change request introduces no new technical issue 
>>to challenge the prior discussions and therefore should not be 
>>considered.  We should stand by the rules we have established.
>>To head off arguments that it introduces something new ... the change
>>request asks for two things:  first to clarify whether actions are 
>>cacheable, and second how an action affects the cache for subsequent 
>>getMarkups.  Is there really any confusion concerning whether actions 
>>are cacheable?  The specification defines no provisions for such 
>>behavior, only markup.  Why do we need to clarify something that is 
>>clearly not supported by the protocol?  As for how actions affect the 
>>cache -- this is precisely the discussion we have had twice prior to 
>>this change request -- and have twice prior voted to not define 
>>invalidation caching in 1.0.
>>    -Mike-
>>Rich Thompson wrote:
>>>Document: Spec
>>>Section: 6.3.x
>>>Page/Line: 39/9
>>>Requested by: Alan Kropp
>>>Old text: [none]
>>>Proposed text: [new section: 6.3.4? Cache Discard] The Consumer MUST
>>>always propagate an interaction to the portlet. If there is a 
>>>perUser-scoped cache for this end-user, as a result of a prior
>>>with this portlet, the Consumer MUST NOT rely on the contents of this 
>>>cache, even if its expiration time indicates it is still valid. The
>>>for this is the interaction will very likely change the portlet's state, 
>>>and therefore must not be diverted by the Consumer in favor of hitting
>>>cache. The Consumer COULD send the validation token from the prior 
>>>interaction's CacheControl in the interaction request, and in the event 
>>>the portlet determines that the state change does not invalidate the 
>>>cached content, will indicate that the Consumer may use the cached 
>>>content, using the response mechanism described in the section on
>>>Reasoning: Make conformance statement wrt caching and interactions.  
>>>believe this aligns us with JSR requirement that actions always propagate

>>>to the portlet.
>>>[RT] While this is close to what we have discussed (& rejected) about
>>>interactions invalidating the cache, I think there is value to explicitly

>>>having the spec say something in this area. 
>>>Alternate suggestion: [new section: 6.3.4 User Interactions and 
>>>The Consumer MUST always propagate End-User interactions to the Producer.

>>>If available, the Consumer SHOULD send the validateTag corresponding to 
>>>the MarkupParms supplied to the interaction invocation. If the Portlet 
>>>determines that the interaction does not invalidate the cached content, 
>>>will indicate that the Consumer can use the cached content via the 
>>>useCachedMarkup flag of a returned MarkupContext structure. 
>>>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>

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>

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] | [List Home]