Since it’s possible that an HttpSession can migrate from one VM to another, the spec designers thought it would be nice if someone bothered to tell the attributes within the session that they, too, were about to move. That way the attributes can make sure they’ll survive the trip.
If all your attributes are straightforward Serializable objects that don’t care where they end up, you’ll probably never use this listener. In fact, we’re guessing 95.324% of all web apps never use this listener. But it’s there if you need it, and the most likely use of this listener is to give attributes a chance to make their instance variables ready for Serialization.
Session migration and Serialization
Now it gets a little tricky...
A Container is required to migrate Serializable attributes (which assumes that all instance variables within the attribute are either Serializable or null).
But a Container is not required to use Serialization as the means for migrating the HttpSession object!
What does this mean to you? Simple: make sure your attribute class types are Serializable and you never have to worry about it. But if they’re not Serializable (which could be because one of the attribute object’s instance variables is not Serializable), ...