Handy But Hidden: Collections.newSetFromMap()

I was reminded again today of how much the core Java libraries have grown over the years.  It can be really hard to keep track of all the nice little features that get added in each release.  Today, I was wishing that there was a ConcurrentHashSet class or some other HashSet-style concurrent collection.  Before implementing something myself, I did some searching on Google and found a nice way to solve the problem.  In Java 6 (a.k.a. JDK 1.6), Sun added the utility method Collections.newSetFromMap(), which allows you to pass in an empty backing Map and get out a Set with behavior based on the underlying Map.  So, here is all I needed to do to build a concurrent HashSet:

Set<Observer> observers = Collections.newSetFromMap(new ConcurrentHashMap<Observer, Boolean>());

I also found a bug/enhancement request in Sun's bug database suggesting that this feature should be documented in any core Map for which there is no corresponding Set implementation, such as WeakHashMap and IdentityHashMap.  Given how long I went without knowing the method existed, I wish they'd done it.

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. :)

ConcurrentLinkedHashMap and Possible Alternatives

I mentioned in an earlier post that a project I'm working on needed a thread-safe class with behavior similar to LinkedHashMap, which maintains the order of entries while allowing sub-classes to set a (rather primitive) eviction policy.  I came upon and started using Ben Manes's ConcurrentLinkedHashMap, with only minor modifications to allow for easier sub-classing.  I've been pretty happy with it so far and have been meaning to take a look at recent changes that he and "zellster" have made since I last downloaded the code.

The same project is also using ehcache for caching.  I was looking forward to the release of version 1.6 and inquired about the expected release date on the developer's forum.  That kicked off an exchange between me and Greg Luck, the lead for ehcache, that eventually led to him mentioning some problems he'd encountered with ConcurrentLinkedHashMap.  I'm going to check in with Ben and let him respond to what Greg said, along with giving him a chance to provide a guess for when his new version of CLHM is likely to be usable.  I also need to look into what Greg was referring to in the changelog for ehcache 1.6 beta5 when he said, "Make MemoryStore eviction policies injectable."  Interesting…

Just to confuse matters, I was also recently looking over some materials discussing Infinispan, which will essentially be the 4.0 release of JBoss Cache, and saw this interesting blog entry on "Implementing a performant, thread-safe ordered data container".  In it, Manik Surtani mentions their newly implemented classes FIFODataContainer and LRUDataContainer, which sound like another plausible way to approach my problem.  I'll make sure to ask more about them in the comments for that post.