Michael Gilfix Online

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: