By jluehe on Oct 01, 2008
Retain session data during redeployment
OverviewThe just-released GlassFish v3 Prelude provides a new feature that is going to become very popular with developers: the ability to retain HTTP session data across redeploys, which is something Jerome Dochez and I have worked on together.
Let me briefly explain what motivated this feature, and why it is so important: When you redeploy a application, the application first gets undeployed, and then its new, updates bits are deployed. During the undeploy, GlassFish is going to remove any and all traces of the application, including its classloader, compiled JSPs, and file-persisted HTTP sessions (in case a file-based persistence mechanism is being used). In addition, any active HTTP sessions will be destroyed. In many cases, a number of HTTP sessions will have been created during each development cycle. After a redeployment, these sessions will have to be recreated from scratch: A tedious and time-consuming task!
How to enable
GlassFish v3 Prelude adds the ability to preserve any active HTTP sessions during a redeploy. A user may request this feature by passing the new
keepSessions property (set to
true) to the
asadmin redeploy command.
asadmin redeploy --properties keepSessions=true --name myapp myapp.war
The GlassFish admin console also exposes this new feature, which has also been incorporated into the Deploy on change feature of Netbeans, which instantly redeploys a WAR- or EAR-based, directory-exploded application as soon as one of its class files or descriptors has changed. Both Netbeans and the GlassFish Plugin for Eclipse allow developers to enable this feature by clicking on the new
Preserve Sessions Across Redeployment checkbox, which can be seen at the bottom of the snapshots taken for NetBeans and GlassFish Plugin for Eclipse.
Behind the scenes, any active sessions will no longer be destroyed during a redeployment if so requested by the user: Instead, they will be stored in memory in serialized form, and restored from memory and deserialized when the redeployment has completed.
If any of the active sessions of the application fail to be serialized or deserialized, a warning will be logged, and the redeployment will continue, but none of the sessions that were active prior to the redeployment will be available following the redeployment.
The new classloader of the redeployed application will be used to deserialize any sessions previously saved. The usual restrictions about serialization and deserilization apply. For example, any application specific classes referenced by a session attribute may evolve only in a backwards compatible way.
GlassFish v3 Prelude simplifies your development cycles and increases your productivity by allowing you to preserve any active HTTP sessions when you redeploy your applications.