One of our customers got excited ”Cool, you support hot deployment”. These days most of the J2EE application server vendors support hot deployment. Application deployment in J2EE has always been a confusing topic for most of the developers and hot deployment has always been a highly marketed jargon. He then requested me to point me a paper that describes the different types of J2EE deployment and best practices and I asked him to do a google search on Hot Deployment and he said it yielded more than half a million results but not a definitive article on Hot deployment. Interestingly the J2EE specifications do not say a whole lot about this and each vendors implement their own way. In this article, I will discuss different types of deployment and examine what are things you need to be aware if you use hot deployment in your production environment.
Archives vs. Deployment directories
J2EE mandates use of deployable archive files like EAR, WAR, RAR, EJB-JAR, etc in the application server for portability. There is no doubt these archives promotes the very cause of portability across various J2EE application platforms but these do not consider very real life use cases for example updating some contents e.g. adding some new contents like new html files into a web modules on fly or patching an application module without having to redeploy the application. Some containers like OC4J and Weblogic provide this nice functionality to deploy applications in an expanded directory format that is really convenient for an environment where some contents GIF, HTML, JSP change almost everyday e.g. a news/media company. Expanded file structure deployment is also very good for development environment, as the developer does not have to package WAR/EAR for small changes during development cycle.
Hot deployment vs. Automatic Deployment
There are still a lot of confusion around Automatic deployment and hot deployment.
In laymen’s language, hot deployment is a process of deploying or redeploying an application without having to shutdown/restart the J2EE container. This is very useful in a production environment when you have multiple applications are running in your application server environment without having to impact users of applications.
Automatic deployment is a process where the container automatically determines change in the application archive and automatically deploys the application. This is really useful feature in a development environment where the developer does not have to perform the mundane task of redeploying the application. Normally the J2EE container keeps on polling the file system to see if there is any changes in the application and when it redeploys the application as soon as there is any changes. Automatic deployment is switched off by default and can be switched on by starting OC4J with system property -Dcheck-for-updates="true” and on in BEA Weblogic by setting
-Dweblogic.ProductionModeEnabled to false.
Automatic deployment is not recommended in a production environment because of the two reasons:
- Container spends significant CPU cycles polling for changes in applications
- Automatic deployment is NOT foolproof in the can have adverse affects on your applications during deployment
Hot Deployment – what does this mean for you
The term “Hot deployment” promises a whole lot to the users in a production environment.
The main benefits of hot redeployment is enabling administrators to a redeploy application without impacting existing user of the application and ability to patch or incrementally deploy application modules without having to redeploy the whole application. However due to the fact that application deployment is dependence on java classloaders these are not foolproof and may create classloading issues to your applications so you have to be careful when you plan to hot deploy an application.
Few are the best practices when you plan to use hot deployment:
- Container Restart is always better than hot deploy. So choose hot deployment only when container restart is not a possibility! Choose a time when not too many users are in the system.
- The libraries at the container level cannot be hot deployed and requires restart. If your newer version of the application is dependent upon a newer library you need to restart your container.
- Redeployment of your application will reinitialize your application so all users may loose their sessions. Application servers can serialize the sessions and restore after deployment. So make sure that you enable session persistence for your applications. You have to make sure the structure of the objects you are storing in session has not changed since your last deployment.
- Verify the dependencies your application with others. If any other application is dependent upon this application you cause problems to the dependent application when you decide to hot deploy the application.
Conclusion
Looking at the hot deployment features supported by various vendors everybody thinks it’s “cool idea” but not robust as it appears. None of the vendors recommend wholeheartedly these in production environment, so you have to be careful when you decide to use this in your production server running your website or mission critical applications.
Discuss this article in http://www.theserverside.com/news/thread.tss?thread_id=26044
2:34:04 PM 
|
