On Sun, Jul 10, 2011 at 6:35 PM, Greg Wilkins <gregw_at_intalio.com> wrote:
> On 8 July 2011 15:34, Wenbo Zhu <wenbozhu_at_gmail.com> wrote:
>> Sorry, I've missed this email.
>>
>> On Fri, Jun 3, 2011 at 1:00 AM, Greg Wilkins <gregw_at_intalio.com> wrote:
>>>
>>> On 2 June 2011 18:41, Wenbo Zhu <wenbozhu_at_gmail.com> wrote:
>>> > The current requirements imply session "stickiness" (for the sake of
>>> > in-memory synchronization) which isn't always desirable.
>>>
>>>
>>> So how do you see the willPassivate, didActivate and binding events
>>> handled?
>>
>> For this model to work, there will be no local state (in theory), and as a
>> result passivate/activate has to be interpreted differently (e.g. ignored).
>
> I agree that such sessions will only work if they have no local state,
> so interpretation of passivate/activate will have to be different.
> But I'm not sure that ignoring them is the right thing to do- as they
> may be useful for at least logging/debug
This is just an implementation concern, isn't it?
>
> We're currently working on a nosql session manager that does support
> this mode and we are looking at firing willPassivate before every
> commit to the DB and didActivate after every save (unless we know we
> are shutting to node down). We except that these listeners will be
> rarely implemented so such actions will mostly be a cheap noop - but I
> think it does respect the existing API contract.
IMO those listeners should be ignored, precisely because the existing
API contract is not involved.
>
>>> If a session is active in node A and node B, and an attribute is
>>> updated in node B, then obviously any binding events will be called in
>>> nodeB. But sometime later a request might go back to node A and it
>>> may realise that it has a stale copy of the session so it will reload
>>> the session (let's say from some NoSQL store).
>>
>> There is no notion of staleness, since the state is only stored remotely.
>
> So that would imply that binding/unbinding events would only fire in
> the node that actually does the setAttribute call (or invalidates the
> session).
Yes.
>
>
> Note that I'm very interested in support this kind of mode in the spec
> and trying to tie up all these kinds of loose ends for portability.
Great. Those API's you mentioned above need explicitly state all the
underlying restrictions under such a "distributed" mode.
Cheers,
Wenbo
>
> cheers
>