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).
> 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.
>
> I also assume that willPassivate and didActivate will be called in
> nodeB around the saving of the state to the NoSQL store - as this is
> already normal for persisting sessions.
>
> But when the new state is loaded into nodeA, what events should be
> fired there? It already has what it thinks is a valid activated
> session. Should the sequence be:
>
> willPassivate to deactivate the stale session
> unbind any attributes that were set in node B (could be hard to
> know, so maybe unbind all attributes).
> bind any attribute values that were set in node B (could be hard to
> know, so maybe unbind all attributes).
> didActivate to activate the cloned session.
>
>
> cheers
>