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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: proposal for issue 234 (WS-Context)


http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=234

It would be good to get the discussion going on this, either by email or 
on Monday's call.

Although I registered the issue, I'm sure this was a result of 
conversations I've had with a number of people (Doug springs to mind for 
one) at various face-to-face meetings. The idea is that the context 
timeout either was inaccurately set or (more likely) simply needs 
extending. Think of it like renewing a session without having to tear 
down and initialise another one.

What I initially had in mind (and ignore names of operations for now) 
was that we add a "renew" operation on the context service that allows 
the value of the timeout associated with the context to be changed 
(maybe downwards as well as upwards).

Now the only issue that this then raises is one of consistency: the 
previous timeout value may be known at different points in an 
application and acted upon (since one aspect of the timeout is that it 
allows recipients to know that a context/session is no longer valid 
without having to go back to the context service). This is a traditional 
cache-coherency problem and one that I don't think we want to get into - 
it's difficult enough in a closely coupled environment!

So, there are two suggestions as to how to handle this aspect:

(i) ignore it and simply say that a recipient MAY use the timeout this 
way, but there are no guarantees.

or

(ii) allow a timeout value attribute that specifies whethere or not it 
is immutable when created. This way a recipient knows that it can act on 
an immutable value as it currently can (e.g., garbage collect things 
when it locally decides the context has expired); for a timeout value 
that MAY change, the recipient can either go back to the context service 
to check (pull down the latest context by value), or risk doing things 
locally anyway.

Mark.
begin:vcard
fn:Mark Little
n:Little;Mark
email;internet:mark.little@arjuna.com
title:Chief Architect
version:2.1
end:vcard



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