Is zero turn-around really a big deal?
Is zero turn around really that important for Java’s core user base? I just read the zero turn around blog entry over at the Aranea Blog and while this is a good question I’m not convinced this is such a big deal.
Let’s face it, the majority of JavaEE applications are deployed in corporate environments where a really quick deploy is generally not a concern. Why? Because most corporations have deploy procedures that happen after hours or during slow traffic times, on weekends, etc. just in case anything goes wrong. Even with and ‘immediate’ deploy time these procedures wouldn’t change because the risk of the deployment itself is still there.
Even with a deployment model like JavaEE, unless you have a really slow server (i.e. WebSphere) or a really big app with lots of EJBs or something, deployments don’t take all that long. Every app I’ve written could be redeployed on tomcat or JBoss in a matter of seconds.
On the flip side I have done some PHP work and it can be really nice to not have to package and deploy when I’m developing and when I move it up to a live server. Even with that I don’t get frustrated when doing Java work because when I’m using my IDE this isn’t a big deal because worst case I restart tomcat and 7-8 seconds later my app is ready. When I go to QA and deploy, it is all done via an Ant script.
The other thing to think about is that with an immediate deploy method, your app may not be ready for use while requests are still coming in. Think of it this way, if your app has a couple hundred files in it and you go to ‘deploy’ that, i.e. copy the files over, unless you shut the server down those files are live immediately and requests will utilize them. This can cause your application to break because certain files are updated that may rely on other files that are not yet copied over. This could lead to outright app failure, security holes, data corruption and who knows what else. With a JavaEE deploy model, most app server will at least suspend the application while it is redeploying, preventing new requests from coming in. Some of the more sophsticated servers will partition the classloaders so that current requests get fullfilled and new requests wait for the new deployment. So in essense this model is far more secure and reliable.
So zero turn around is nice, but not essential for JavaEE applications.
![](http://a1.twimg.com/profile_images/469006682/foto_twitter_normal.jpg" rel="image){kind=small}
![](http://s.twimg.com/a/1257465343/images/default_profile_0_normal.png" rel="image){kind=small}
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
[...] There has been some amount of discussion on the previous post. What was a bit surprising for me, is that a lot of people think that this isn’t really an issue for Java EE (they should really look at the comments here). [...]