Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:This just seems like nonsense. (Score 2, Interesting) 160

by Karl Harbour (#22003134) Attached to: Rails May Not Suck

Has it really? I don't think that Java has survived the lack of mod_java.

Quite. Apart from the lack of Java in the hosting space, let's be honest, the whole Apache->Tomcat connector story has been a sorry one indeed. mod_jk, mod_jk2 etc has been a real mess over the years.

Where does this stem from? I think it is a case of the wrong tool for the job again in a way, this time by Sun.

Originally Oak (Java) was designed to run on set-top boxes, where it made sense to have a long-running virtual machine. The web took off just as Java 1.0.2 was launched with a whole 6 packages. Not long after, Apache was the prevalent web server, and worked well for static content. Dynamic content was served by CGI, and that didn't work too well because every request required launching a separate process.

So PHP comes along and quite nicely solves this problem by running in an Apache module, with the requests handled in forked Apache child processes (pre-fork MPM).

This model doesn't fit with the virtual machine architecture of Java - you can't have multiple copies of the VM in each of Apache's children. So we end up with the mod_jk architecture.

I used to think that the PHP MPM Apache children approach was a bad thing, compared to the ability to create threads, caches of shared data, database connection pools etc in Java. But the PHP shared-nothing architecture has definite benefits.

For one thing, it gives you isolation. If one child fails, other children are unaffected. In my experience, the PHP architecture is more robust, for example, in the case of recovery from database failure. I've seen Java web apps where if the database is restarted, invalid connections stay in the connection pool and you have to restart Tomcat.

Also, horizontal scalability is so much easier. Java has solutions to this, but it's a bit of a mess in some ways. Of course I don't think PHP is a better *language*, but the reason HTTP itself has been successful is because of its statelessness. The PHP shared-nothing architecture respects that, Java goes against it.

That, in my opinion, is why PHP rules the roost on the public internet.

"There is such a fine line between genius and stupidity." - David St. Hubbins, "Spinal Tap"

Working...