Interruptible JDBC Statements

I work for a client on a product that makes direct queries against databases via JDBC. A while ago, I added some code so that a user could stop the execution of a series of queries by clicking on a cancel button. Behind the scenes, it interrupts the thread executing the queries. Since that thread checks whether it's been interrupted by calling Thread.currentThread().isInterrupted() before starting to execute each query, no new queries will start once the cancel button was pushed. However, any query that's already started will run to completion before the code discovers that a request to cancel had been made. Recently, my client decided that we should make cancellation more granular and add the ability to stop a query in mid-stream. Looking at the JDBC docs, there's nothing to indicate that any of the relevant methods respond to interrupts (none throw InterruptedExceptions or claim to wrap them in a SQLException), so I had to come up with another way. I settled on an approach where I submit the query as a Callable to an ExecutorService and then block, waiting for the result via Future.get(). If the thread is interrupted while we're waiting, get() throws an InterruptedException, which gives us the chance to call Statement.cancel(). It's pretty simple and works nicely. :)
Here's the code in a somewhat abridged/condensed form (I create the ExecutorService elsewhere using Executors.newCachedThreadPool()):

final String sql = "...<some SQL>...";
final Statement statement = conn.createStatement();
Future<ResultSet> queryFuture =
 execService.submit(new Callable<ResultSet>() {
   @Override
   public ResultSet call() throws Exception {
     statement.execute(sql);
     return statement.getResultSet();
   }
 }
);

ResultSet rs;
try {
 rs = queryFuture.get();
} catch (InterruptedException e) {
 logger.info("Query interrupted - calling Statement.cancel()");
 statement.cancel();
 throw e;
} catch (ExecutionException e) {
 //code to handle or rethrow the exception
}

By the way, if any of the java.util.concurrent classes above are unfamiliar to you, I highly recommend Java Concurrency in Practice by Brian Goetz (et al.). It's an excellent book.

Terracotta Acquires Ehcache

Exciting news!  This morning I received a note from Greg Luck via the Ehcache Open Discussion mailing list announcing that the Ehcache project was joining forces with Terracotta and that Greg would be joining the team at Terracotta, Inc.  Since there's been a Terracotta Integration Module for Ehcache for a while, I don't foresee any instant improvements with regard to integration between the two technologies, but I was quite excited to see the following in Greg's blog post announcing the news:

I am full-time on Ehcache. I have not had the time I would have liked to devote to Ehcache (I have been doing a miserly 10-15 hours per week for the past 6 years) but now I do. Look out!

Given what he's done so far with limited time, I'm looking forward to seeing what Greg can do when Ehcache becomes his full-time job!

For more information, see Terracotta's announcement, CTO of Terracotta Ari Zilka's blog post, or Alex Miller's blog post.

p.s. I submitted a patch that Greg ended up incorporating into Ehcache 1.6, so I feel a tiny bit of ownership toward the project – similar to the way I feel toward Tomcat.

Update: Terracotta and Ehcache are holding a webcast on August 20th at 4PM ET to further discuss the acquisition.  Also, I just submitted my second patch to Ehcache. :)

Attending SpringOne 2GX in October!

After much thought, I finally decided last night to register for the SpringOne 2GX conference running from October 19 through 22 in New Orleans.  The deadline for the super-early bird pricing is this Friday (July 31), so I thought I should make my decision.  I've been to talks on Groovy and Grails at NFJS and JavaOne, but I'm really looking forward to an entire conference devoted to those topics.  I hope to see you there!

FogBugzReporter: NetBeans + Ivy = IvyBeans

(This is my second post in a series about FogBugzReporter, a small open source app that I originally wrote in Java and later ported to Groovy.  See the first post for more information and for links to other posts in the series as I write them.)

When I first ported FogBugzReporter to Groovy, I was able to take advantage of a free 1 year license for JetBrains IntelliJ IDEA (version 7) and its nice Groovy support.  I had good experiences with it, but when the year ran out, I was both reluctant to pay for a new license and curious to explore the Groovy and Grails support in NetBeans.  At the same time, I was interested in trying out Apache Ivy for dependency management.  As it turns out, Laurent Forêt wrote a plug-in for NetBeans called IvyBeans which integrates Ivy with the NetBeans internal build infrastructure.  So, if you reference a library in your ivy.xml, not only is it downloaded into your local repository (located in %USERPROFILE%/.netbeans/<netbeans_version>/modules/ext/cache on Windows) but it's also added as a NetBeans project dependency.  This post describes what it was like to move to NetBeans and start using Ivy.

Although I'd previously used NetBeans 6.1 and 6.5 for some small Grails apps, by the time I got around to moving FogBugzReporter into NetBeans, the 6.7 release process had already reached Milestone 2 or 3 (it has since been released!).  Since the Groovy/Grails plug-in for 6.7 provided better, more up-to-date support, I decided to jump directly to it.  After installing the base version and adding the Groovy/Grails plug-in, I looked over the options for opening the project in NetBeans.  I couldn't see any easy way to either import the project based on the existing IntelliJ files or create a new project pointing to the existing sources (any suggestions?), so I ended up doing something weird along the lines of creating a new project and checking out the files from Subversion on top of it.  I don't remember the exact steps, but even if I did I might not repeat them here, since I'm sure there's a better way to do it.  Once that was done, I was a bit disappointed to discover that I was unable to designate my Groovy script (MainFrame.groovy) as the project's main class.  This was even true after I converted the script into a class and gave it a main method.  Fortunately, it's still possible to run the app inside NetBeans by selecting that file and choosing Run File (Shift+F6) from the Run menu.

Next, it was time to try out Ivy and IvyBeans.  At the time, there was no up-to-date build available, so I built from HEAD, but at this point you can just download 1.1 Milestone 3.  Installation is as simple as extracting the zip you just downloaded and then following the basic plug-in install steps.  I searched on MVNRepository.com to find the appropriate org (a.k.a. group) and name for each of the two libraries my project uses.  I then removed the libraries from the NetBeans project, temporarily making the IDE unhappy.  After I added lines of the following form to ivy.xml and then executed a Clean and Build on the project, Ivy downloaded the libraries, IvyBeans made them available to the project, and the build completed successfully.  Pretty cool!

<dependency org="com.something" name="library_name" rev="1.2.3" conf="compile->*" />

My transition to NetBeans isn't totally finished, but it's almost there.  One thing I still need to figure out is what changes are needed to allow me to run an external build using the ant build.xml file generated by NetBeans – I think it involves specifying a few properties that are currently absent when ant is run standalone.

As I've said in most of my posts, please tell if you know of a better way to do any of what I've described above.  I'm definitely not an expert in NetBeans or Ivy.