Getting Around the Double-Checked Locking Problem

This is just a summary of alternatives to the double-checked locking pattern, which has been shown to have potential problems. The alternatives are taken from a CERT wiki article. The motivations for the pattern come from three concerns:

1. avoid constructing an object that is expensive to construct, unless-until it is needed
2. avoid more than one instantiation of that object, and
3. avoid the overhead of synchronization for the more common case of fetching the object.

Getting Around the Double-Checked Locking Problem

This is just a summary of alternatives to the double-checked locking pattern, which has been shown to have potential problems. The alternatives are taken from a CERT wiki article. The motivations for the pattern come from three concerns:

1. avoid constructing an object that is expensive to construct, unless-until it is needed
2. avoid more than one instantiation of that object, and
3. avoid the overhead of synchronization for the more common case of fetching the object.

Thread-Safe Singleton Using ThreadLocal

Let's say a given component in your application has these constraints:

1. it needs a reference to an object that is expensive to construct
2. the expensive object state can be set just once, i.e. it never changes
3. it executes in a multi-threaded context
4. maximum throughput is required

Constraint #1 seems to call for an instance variable - i.e. you don't want to use a method-local field since the object construction is expensive, as such you don't want to do it each time the object is needed. Constraint #2 implies that a singleton will serve our needs. However, constraint #3 means the singleton must be used in a thread-safe manner - and constraint #4 tells us that we want to avoid synchronization if possible.

Get Notified When Your Periodic Task Throws an Exception

I've written up a how-to on a periodic task with a watchdog; now I want to handle exceptions and notify interested observers when exceptions occur. The watchdog is in place in case exceptions don't get handled at all, in which case subsequent executions of the scheduled thread will be suppressed. in this case, the watchdog knows that some problem occurred - but it doesn't know just what that was. As an alternative (or in addition) to the watchdog, we simply catch exceptions in the Runnable passed to our Executor, handling it by both logging the information and notifying interested listeners. This helps pass along exception information from a different stack of execution, since the problem occurs in a different thread:

Use Spring to Wire Up Varargs

This describes a technique to provide N objects to a constructor using Spring. Nothing real new or innovative here; just an idiom I wanted to save for future reference. Let's say we have a constructor that uses varargs:

    public MockDao(SummaryData...summaries) {
        // save the summary data for downstream use...
    }

And, we want to use Spring to provide test summary data to our mocked-out DAO.

Encapsulate SSL TrustStore Configuration

Here I'll present the steps of a recent exercise I completed, around configuring SSL on the client side, encapsulating the configuration for transparency. For some background on SSL and the topics discussed in this article, here are some resources:

SSL Protocol Overview
SSL Certificates HOWTO
Transport Layer Security

The Security Now podcast series also has some excellent deep-dives into SSL and many other security-related topics.

Enable Assertions with JUnit Tests in IDEA

My test cases have recently been converted from TestNG to JUnit4, and to my surprise every single test I wrote from that point forward passed without a problem - if I ran the tests in my Intellij IDEA 9.0.4 IDE. Mysteriously, executing them via Maven did not have that same result (whether from command line or from IDEA). As it turns out - apparently JDK assertions are enabled by default when I use TestNG in IDEA, but not so much when using JUnit.

Fix this problem by setting the -ea VM argument for all existing tests, and setting that as a default for JUnit tests created from this point forward.

Arrrggghhhh.