Another interesting sentiment that I recently heard is that programming Web sites in Java is hard because it involves threading, and threads are hard. I would like to know more as to what the roots of this argument are; but here's a few obvious things to consider:
(a) If you program in JSPs or Servlets as you are expected to, you have no reason to even worry about threading (so the fact that JSPs and Servlets are multithreaded adds no complexity to the application). Recall that your stuff inside JSPs gets mapped to a method call when they are compiled into Java code. By default, this means no static class variables. You can, of course, have static blocks in JSPs, but you need to be an experienced JSP developer to know how to do that (which hopefully ensures that you know what you're doing). With Servlets, it's a bit easier to create static class variables, so you need to pay more attention. But it's not like you have to manage the entire life cycle of the threads; the web container takes care of it for you. So, I don't really see how servlet or JSP applications get more complex because of threading.
(b) Struts is a bit more complex, true, but you don't really have to use Struts, especially if your focus is on performance. I am not saying here that Struts is a bad idea, of course, I am just saying that the framework carries an additional complexity along with it, and it therefore expects a higher level of skills from its exploiter.
(c) There's this related argument that Java supposedly scales through threading, that it pushes you to use one gigantic JVM and so on. Again, I don't fully understand the argument here. The size of the thread pool that you use in your web container (Tomcat, Resin, whatever) is a configurable parameter. So from the thread perspective, your appserver JVM has just as many threads as you want it to have. If, for whatever reason, having just one JVM serving requests out of the physical box is not optimal (which is usually caused by poor quality coding, by the way), it is very easy to vertically clone appservers. This gives you multiple logical appservers (or JVMs) on the same physical box, is supported by practically all appservers, and does not cause problems in most cases. Someone mentioned inter-JVM communication. Vertical cloning typically does not require inter-JVM communication because of session affinity, which again is widely supported today. You may wish to have this communication when you are maintaining a large object cache (which you probably should be doing if you are Friendster), but you'd also want it anyway with horizontal cloning.
Anyways, I would appreciate it if someone could elaborate on what they meant in regards to these threading issues. Clearly, Java threads are lots easier to code to than, say, pthreads. And of course, having a thread pool is faster than forking a new process each time. If you want to beat Java threads, you need to code with pools of pthreads, and I suspect, this is what you will have to do sooner or later in order to support a PHP tier for a site like Friendster. Isn't this what Yahoo! had to do for their middle-tier?
Posted by Dima Rekesh at July 9, 2004 06:38 PM | TrackBack