Web service clients and concurrency

Web services are probably the most common mechanism for distributed systems integration online at the moment.

In the Java world there are tools available to generate classes to act as remote proxies and interfaces.

Apache Axis and Axis2 provide a wsdl2java command line utility for generating these Java classes from a web service's WSDL file/URL.

What some people may not consider is that the implementation details of the stub which their client code will call, may not actually be safe to be called from multiple threads at the same time.

So, if you have a multithreaded application - such as a web app - where multiple threads could potentially be making calls on the web service via a shared instance of the generated stub then it is possible that some state that is set up as part of the processing of one thread could be changed by another thread.

It may not be apparent from looking at the generated code, but ultimately that code extends code buried within a jar that you do not have control over.

There are several approaches to avoiding the problem:
- create an instance of the stub for each call
- create and access stubs in a thread local way
- set up a pool of stubs, much the same way as database connections are often pooled.

I'm going to try out CommonsPoolTargetSource for the pooling approach.

Implementation of the Singleton pattern

The last successful job interview that I had included a minor practical pen and paper exercise - "Show me how you would implement a Singleton in Java".

I'd been using the Singleton pattern for about 6 years by this stage, so I just jotted down the most basic implementation that I knew, something along the lines of:


public class Singleton
{
private static Singleton instance = new Singleton();

private Singleton()
{
}


public static Singleton getInstance()
{
return instance;
}
}


As I was doing this I thought of all the fancy examples I had seen in various projects that I have worked on and code snippets from various books that I had been reading at the time. So I did my typical self-deprecating thing of saying out loud, "I should probably have some lazy instantiation happening in the getInstance, but that could just be premature optimization".

That lead into a discussion with the interviewer who congratulated me on being one of the few candidates who had actually produced a truly threadsafe implementation. If I had delayed the instantiation until the getInstance was called, then I would have had to introduce some synchronization to prevent the possibility of the instantation happening multiple times, something along the lines of:


public final class Singleton
{
private static Singleton instance;

private Singleton()
{
}


/**
* synchronized to prevent multiple instantiations of Singleton
*/
public static synchronized Singleton getInstance()
{
if (instance == null)
instance = new Singleton();

return instance;
}
}


Then the overhead of the synchronization would have been introduced for each and every call to getInstance - not ideal.

Head First Design Patterns gives a good overview of a slightly better approach involving double-checked locking that I have added to my repertoire (suitable for JVMs 5 and upwards).