19 May 2010 - Digital Strategy // By Productive Edge Team

Thou Shalt Not Thread!

In the beginning... there was JDK 1.0, and everyone learned to write threaded code. Compared to using C++ on Windows (my background before Java), this was a liberation, the Java threading API were simple, easy to use, but most of all.... they worked as expected.


Then came J2EE and the general mantra towards threads changed. All Java Enterprise specs and vendors pretty much said the same thing: "do not write threads, use them from container". The question "why" arose from time to time, but I have not heard a good intelligible answer once. To me this recommendation sounds pretty much like: "you the dumb application developer just do not have enough wits to get correct threading code right, just leave it to the professionals  - us the container developers".

All this would be fine, except one small problem. There is no standard Java API we can use in a container to consume container-provided threads in a lightweight style. I wish we has something like this:

javax.something.AsynchRunner.run(myRunnable); 

..where myRunnable is an instance of a java.lang.Runnable interface. Current business requirements quite often prompt for such functionality inside web applications. Think of collecting statistics, sending emails, writing to files, logging info to log files. All these functions done in the context of a web request slow down page rendering as a side effect.
Java has been around for ages, but this seemingly necessary piece has been missing.
All my searches as to why we cannot (rather should not) create our own threads inside a container came up empty-handed. The only direction everyone is pointing is JMS. While I'm a fan of JMS in general, it seems an overkill in many of the situations I listed above. Here, at ProductiveEdge, the folks are so receptive of open source movement, that I think I will pitch an idea of an open source project for lightweight in-container asynchronous processor, which would be different than that of Quartz, since it will process requests immediately and will have ability to scale number of threads up or down dynamically. This could easily be implemented as a jar library with a built-in thread pool, priority controls, watch dogs, timeouts, etc.
Having implemented an application server (small and lightweight), and thread pool, JSP-like engine, as well as DB connection pool back in Java version 1.0, this does not seem like a difficult task to me.

Anyone out there have the same mindset?

cheers
igor

Share
Thou Shalt Not Thread!