I would like to add a more focused question: Does GF serialize running sessions before a redeploy, and does GF deserialize them afterwards?
Apart from Glassfish, there are hard limits on what you can change in an application while keeping a user session running, both when changing the domain logic and on the class loading level. If the change is not within these limits, no server can keep the user session. As a rule of thumb, small defect fixes can be restricted within these limits, new or changed functions are over the limit.
In the domain logic, for instance, you cannot change pre- or postconditions of user actions. Say step A (old) ensures that a condition X holds, and step B (old) relies on X. Now you change this structure, say A (new) ensures Y as well, and B (new) assumes X and Y. If you migrate a user session after step A (old) to the new implementation, the next step B (new) will fail, because Y does not hold.
Technically, all session information is managed as instances of classes in the server. Whenever a new application is deployed, a new class loader instance reads the new archive file and loads new classes. The information of running sessions, however, uses instances of the old classes, loaded from the old version of the archive file.
The only way to migrate the session information that I can think of is as follows:
1) serialize the user session with the old classes
2) deserialize with the new classes
Of course, this will only work if no new information is needed in the new version (which would be a change in domain logic), and if the classes have the same serialized form on the Java level, for example the same serial version ID.
So the question again: given the domain logic does not change (too much) and the classes are kept compatibel with respect to serialization, does GF migrate the user sessions?
[Message sent by forum member 'wfrech' (wfrech)]
http://forums.java.net/jive/thread.jspa?messageID=264776