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