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