Session lifecycle events

The sesssin was created:
when the　Container first creates a session,At this point ,the session is still considered new(in other words ,the client has not yet sent a request with the session ID)
the session was destroyed by calling the session's invalidate() method.

Attributes:

an attribute was added:
when some part of the app calls setAttribute() on session.

an attribute was removed:
when some part of the app calls removeAttribute() on the session.

an attribute was replaced
when some part of the app calls setAttribute() on the session,and the name of the attribute has already be bound to the session.

[size=large]Migration:[/size]
The session is about to be passivated
when the Container is about to migrate (move) the session into a different VM.Called before the session moves ,so that attributes have a chance to prepare themselves for migration.

the session has been activated
When the Container has just migrated (moved)the session into a different VM.Called before any other part of the app can call getAttribute() on the session ,so the just-moved attributes have a chance to get themselves ready for access.

Only HttpSession objects move from one VM to another.
There is one ServletContext per VM,There is one ServletConfig per servlet,per VM.
But there is only one HttpSession object for a given session ID per web app,regardless of how many VM's the app is distributed across.

if the vendor does support distributed apps ,then the Container is required to migrate sessions across VMs.And that includes migrating session attributes as well