Most everyone who works with server infrastructure has figured out how to use NIO - in one form or another - to transform the standard blocking threaded server model into a far more scalable beast. Without going into boring details (see here, for example, if you need to investigate), the executive summary of the transformation is that previously servers had to pretty much dedicate a thread per inbound socket which would basically block on the socket between requests, waiting in desperate silence for some bytes to show up from the client. The reason why this had scalability issues is that the server had to dedicate a thread per client and threads are really frickin' expensive resources - especially if most of the time they are blocked waiting for the client to do something.
What NIO allowed server architects to do was - at the simplest level - dedicate only a single thread to handle the waiting for a client socket to become active. Once a client socket was found which needed attention, this socket could be handed off to a thread pool where a thread could be picked up to handle the incoming request. This has a quite amazing effect on the scalability of the server as most of the times clients don't do anything at all - something captured by "think time" in simple benchmarks. And since you're blocked doing nothing, you can't use the valuable thread resource to actually accomplish work for some client which actually does need your attention.
Now, this is actually pretty good stuff and has enabled infrastructure to scale far beyond where the old, blocking, architecture could ever touch. However, what's pretty much universal in these server architectures - and perhaps is a well known dirty secret - is that once you get into the actual request processing, the system is back into the old same blocking regime. You can see this trivially, for example, in the Servlet API. When you - the application code - try to read some bytes from the client using the ServletInputStream, you'll find that if the client hasn't sent the bits, or the network is slow in getting them, or any number of reasons, your code will block waiting for those bits to show up. Likewise, if you try to write some output bytes to the client, using your ServletOutputStream, you'll find that your code will be blocked until the OS can buffer those bytes for later output to the network. If those buffers are full you'll simply block until they become available, or the client disconnects.
This isn't any big revelation, but it is surprising to listen to people wonder why we can't use NIO to take care of these issues so we can have even more scalability in the server. I mean, if the API is blocking - as all java.io.Stream APIs are - it's kind of baffling to think that someone believes that we can magically make that blocking action go away and somehow eliminate the thread which is holding the execution state of the application code (and server invocation code) up until the point where the blocking read or write occurs.
Well, I'm pleased to say that I believe that I've discovered a way to magically make the blocking reads and writes "disappear" without having to change any of the JEE Servlet APIs. Well, "discovered" really isn't the right word, seeing as how the technique is not really any new revelation to people "in the know". However, doing this magic for pure and simple Java without redefining the existing APIs, nor requiring the application code to be rewritten in any way is something that I think is pretty magical and certainly at least deserves the characterization of a "discovery". Further, this technique can be applied to JDBC or any other high value blocking API to transparently transform it into a threadless, non blocking API.
So, I was thinking more about the topics in the last post and was wondering about how to go about the transformation of the JDBC implementation and what kind of cooperation would be required with the various driver implementations to pull it off. Originally, my thought would be to make the non-blocking transform at the boundary of the JDBC API, itself. The idea being that there would have to perhaps unpleasant details I'd have to deal with at the driver implementation level and I'd likely need the cooperation of the vendor in some fashion to carry it out.
The prize of the two is 
