[Bug 234] refresh context

[bugzilla-daemon@arjuna.com]

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

mark.little@arjuna.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED



------- Additional Comments From mark.little@arjuna.com  2005-04-13 11:46 -------
In the last teleconference I got an action item to further develop the proposal
for changing the timeout associated with a "running" activity. I hope we're all
now clear after the teleconference that the current setTimeout operation on the
context service only changes the default timeout value associated with contexts
created subsequently without the timeout parameter on begin?

With that in mind, the discussion we had centred on having a proposal for adding
another operation to the context service that allows the timeout for an existing
activity to be changed, but to say that referencing specifications MAY impose
limitations on when it can be used. That proposal is what follows:

That we add an updateTimeout operation to the context service. This operation is
contextualised, i.e., a valid context MUST be present with the message. The
context service then changes the timeout associated with the context (which may
be longer or shorter than the context's current timeout value). Because the
timeout value MAY be mutable, we need to make it clear in the text that
recipients of a context SHOULD NOT rely upon the value for making local
optimisations (such as garbage collection) unless a referencing specification
places limitations on how/when updateTimeout can be used (at the limit, even
making the timeout value immutable).

Mark.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.