Michael Gilfix Online

I have a friend who recently joined a startup in San Fransisco, where they are looking to start development on a product in addition to their consulting business. This prompted a good conversation on what technologies to use when starting a product from scratch with a wide open playing field on choices. There's definitely no one-size-fits-all answer here; the technology choices will be influenced both by the needs/goals of the business and the nature of the application.

The interesting part of the conversation was identifying the questions / criteria to use in guiding the decision making. The answers to these questions definitely vary depending on the growth plans of the business (e.g., is the goal to scale to a big development shop? Is this a small auxiliary effort to a core business like consulting?). Technology choice is about investment. It's the foundation for building something that must be evolved and supported. In my friend's case, time-to-market, cost, productivity, and agility were necessities of the startup environment.

The following questions seem pretty helpful in guiding the decision making, regardless of the particulars of the technology:

• What skills do I have available right now?
• Do I have confidence that my technology choices will be able to meet the evolution of the business?
  • Will the application be able to scale?

Here's a cool trick for structuring debugging of DOJO applications. This technique originated from Rhys Ulerich, who work in WebSphere Telecom Web Services Server development. Rhys is working on an interactive web-based console on top of WAS 6.1 for the much improved Service Policy Management Console in our upcoming release (targeted around October time frame). This technique allows you to enable debugging from the server side (via the app server facilities) of DOJO logic that executes client-side.

The technique has two elements to it that are embedded into the JSPs that render the console contents. These JSPs also render the appropriate DOJO widgets, JavaScript, and UI contents. First, the following is used to determine the trace logging:

<%@page import="java.util.logging.Level"%>
<%@page import="java.util.logging.Logger"%>
<%!
    //  "this" is the compiled JSP class for either
    //  a) ScriptPreamble.jspf if using jsp:include
    //  b) including JSP page, if using @include
    final Logger logger = Logger.getLogger(this.getClass().getName());
%>

As part of deployment, JSP contents are compiled into corresponding Java classes that are used to output the JSP contents. This can be done as part of deployment or through pre-compilation. This code snippet creates an instance of the Java logger class as part of the JSP generated class. As a byproduct, this will register the logger instance with the WAS trace logging subsystem as part of class loading.

Double checked locking is a useful paradigm for avoiding the cost of unnecessary synchronization and is often used in the context of avoiding synchronization during lazy initialization. The basic idea behind double checked locking is that you check variable condition first, and if the condition is not met, then synchronize, perform the check again, and adjust the condition. The second check inside the synchronized block typically serves to avoid repeating the actions that were used to satisfy the condition in the first time. There are quite a few articles on the web on this topic. However, some are incorrect, provide only partial information, or are quite complicated. This is an older, but enduring topic. So here's an attempt to distill it down.

The basic problem that double checked locking is trying to alleviate are conditions like this:

public class Foo {

  private static Foo instance = null;

  public static Foo getInstance() {
    synchronized(Foo.class) {
      if (instance == null) {
        instance = new Foo();
      }
    }
    return instance;
  }

}

Here, synchronization needs to occur for every fetching of an instance. This same pattern applies to any other lazy execution of static initialization that is undesirable to be repeated. The often cited and incorrect solution to this problem is code that looks as follows. This code implements a double-check locking approach to avoid synchronization of the typical execution path:

I've found that time and time again, when developing on top of application servers and frameworks, that many developers do not fully understand the threading model that they are working in and its implications. In a larger development shop, this can be difficult to catch until late in the development process. Typically, the design of the component in question is sound (and goes through the review process), but the implementation architecture (structuring of the code) does not consider these details. The problem is too close to the code and typical unit testing does not simulate a multi-threaded environment. These problems tend to be discovered either through code review or at the start of system test (functional test also typically tests one thread of execution), both of which tend to happen later in the cycle -particularly on projects with tight schedules and resources and which project doesn't fall into that category?

Once discovered, these problems are fixable, but typically the solution is of lower code quality than had the code been written with multi-threading in mind in the first place. By lower code quality, I mean that the code tends to exhibit higher defects and often times lower performance. For example, a developer keeping multi-threaded code would try to reduce the number of locks acquired and time the locks are held by consolidating update to state in a single location in the code in a particular path of execution. A developer unaware of the cost of synchronization (or that synchronization was even needed at all at first) might spread out the updates throughout the code. When the time comes to add locking, locks must be distributed throughout the code, typically resulting inefficient acquiring and releasing of the same lock. In addition to being more error prone, this code is also more difficult to maintain. When another developer takes over the code, it can be hard to surmise the concurrency strategy in the code and the effects of change.