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
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.
>> 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).
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.
cheers