Most read:
Popular archives:
JavaWorld's new look is here!
We've upgraded the site with a fresh look-and-feel, improved topical navigation, better search, new features, and expanded
community platform. Learn more about the changes to JavaWorld.
| Oracle Compatibility Developer's Guide |
| The Explosion in DBMS Choice |
Many software developers do not pay enough attention to the shutdown (also referred to as undeploy) of the applications they
write. In fact, the most popular shutdown mechanism is to execute Ctl+C or a kill -9. However, if you are writing an application that coexists with other applications on the same application server, then a
kill of the application server kills all the resident applications. You may need the ability to shut down your application,
ensure that all resources consumed by it are released, and clear its memory footprint while leaving the other deployed applications
running. In this article, I provide code samples for how to do that, and identify a set of checks and techniques.
Besides releasing resources, another important aspect of the shutdown process is ensuring your system is in a consistent state and mission-critical data is not lost. If your application processes transactions via Web service calls or batch loads, it is important that you bring those ongoing transactions to a halt smoothly; this article examines some techniques that can help you achieve that goal. Further, I discuss the usage of tools like JConsole and Borland Optmizeit to ensure a clean shutdown.
I will desist from presenting a formal definition of Web application shutdown. But, for practical purposes, one can say that an application has shut down when all the threads either started by it or servicing it have terminated their processing, and when memory used by the application during its lifetime, including object instances and class definitions, becomes unreachable from any of the currently live threads. Effectively, the memory used by the application during its lifetime becomes a candidate for garbage collection.
Application server front ends are available that allow you to deploy and undeploy Web applications. In the case of JBoss and Tomcat, the shutdown front ends are based on Java Management Extensions (JMX): when your application is deployed, the application server creates a managed bean (MBean) to manage its lifecycle, and when you undeploy an application, that MBean's undeploy method is invoked. You can also invoke such MBean operations from command line utilities. In addition to the JBoss JMX Console, JBoss supplies a utility called twiddle that invokes MBean operations from the command line.
When you undeploy a Web application, the container (through MBeans, in the case of JBoss) ultimately calls the destroy method on all active servlets. Applications typically have a singleton launcher servlet that performs the initialization and is placed as the first servlet definition in the web.xml file. Servlets are initialized in the order in which they are defined in web.xml and destroyed in reverse order. Cleanup code can be written in the launcher servlet's destroy method.
In standalone applications, you can notify your code to initiate an orderly shutdown through JVM hooks.
In this article, I take the case of a simple Web application that helps a database operations administrator request for, analyze, or truncate tables via a Web UI, and illustrate how shutdown is implemented. The operations requested via this application can take a long time to complete and are handled asynchronously by a thread pool, as illustrated in the code below:
Archived Discussions (Read only)