How hot deployment works internally?

Question

I am using eclipse server capability for hot code deployment. Using tomcat as web server. But i am not sure how it works. I have my own understanding how it must be working internally.

My understanding :- When developer make the changes in code(say class Employee), Eclipse will place/publish the modified compiled class at right location(must be specific web/app server. lets call it hot deploy directory(HDD)) under webserver. Now web server specific class loader will come in to picture. It finds the new entry under HDD. Now, it finds if class has been already loaded by classloader in perm gen space, webserver will unload it from permgen space and load the new the one internally without server restart so that new changes(byte code) is reflected . As part of reload, webserver will also link the existing Epmloyee objects with new class definition in perm gen space so that new changes are reflected.

Is my understanding correct ?

Some links like this says Eclipse hot deployment is just automation of redeployment. what i believe it means is that eclipse automatically stop the server , republish and restart it without developer intervention. Buti i think its not true as this process is really quick as compared to start/publish/restart. Also if it would have been true, how session and other live objects will remain live after restart ? May be this link was true in past but not now as I find hot deployment works for classes in jar also

Answer 1

Hot code deployment depends on the runtime capabilities. The answer you linked to does not mean that the automation stops the server deploys the new code and starts the server again. This would have been wasteful.

Instead, most of the Java application servers are able to redeploy the application. It means that the server would create a new web application class loader, load the new version of the application by this new class loader, in some cases it will migrate state (serialize/deserialize HTTP session), and drop the old version of the application.

Now the redeploy speed depends very much on the application itself -- how the application is initialized. Does it have to warmup caches? Does it have to satisfy the dependencies (a-las Spring, CDI)? Does it have to initialize Hibernate SessionFactory? Many factors are involved.

What Eclipse WTP naturally does is that it can trigger the redeployment process for the application container - that's it. A small application will not take long to redeploy, of course.

Unless there's a special runtime technology/container/framework and there is a special connector developed for Eclipse to take advantage of a hook that would trigger hot code updated for that specific technology. A good example is bndtools for OSGi runtime.

And just to remove some confusion:

Often people confuse HotSwap and hot deployment. The first one, HotSwap, is the ability of JVM to update class definition at runtime. The latter one, hot deployment, is the ability of application server to automatically deploy application, either incrementally or not, without restarting the JVM process.

So my answer is about hot deployment, and not about HotSwap. Hence I refer to hot deployment as an "automation" rather than a fundamental mechanism of the platform.