The Ground Rules

 

---

Threads and Synchronization

Threads and synchronization are discussed in the Miscellaneous lesson. This section discusses in general the issues that a service provider developer should be aware of regarding multithreaded access and the use of threads in service providers.

 

 

Context Implementations

The JNDI defines the Context interface and subinterfaces to which a service provider must implement. Thread-safety with respect to concurrent access is an implementation issue. However, the JNDI does make some common sense recommendations on what the API user and service provider should expect.

• Access to a single Context instance must be synchronized.
• Access to separate Context instances need not be synchronized, even when the separate Context instances are seemingly related.

The first rule means that the service provider need not worry about protecting access to resources used by a single Context instance against concurrent multithreaded access. Callers are responsible for synchronizing their accesses among themselves. This rule allows context implementations to be optimized for their most common thread usage mode.

The second rule reminds service provider writers that when Context instances from the same context implementation share resources, those resources must be protected against concurrent access. For example, multiple Context instances commonly share the same underlying network connection. The network connection in this example would need to be protected against concurrent access. This rule is motivated by the fact that the callers cannot be expected to be aware of any underlying relationship between different Context instances and surely cannot be expected to synchronize access to different Context instances. Therefore the service provider must ensure that different Context instances behave as individual, independent entities and hide any implementation relationships.

 

 

Factory Implementations

An object that implements any of the following interfaces and abstract classes (and their subinterfaces) should be reentrant. That is, multiple threads should be able to invoke methods on a single instance of a factory concurrently.

• InitialContextFactory
• ObjectFactory
• StateFactory
• ControlFactory

Most factories are stateless, so this reentrancy requirement really is not much of an imposition on the implementation.

 

 

Use of Threads

Threads are a useful tool for building system software such as a context implementation, especially when the implementation needs to deal with the network. In fact, threads are indispensable if a context implementation is to support event notification as described in the javax.naming.event package (see the Event Notification lesson).

You may use threads when building components of a service provider. However, be aware that the Java 2 Platform, Enterprise Edition, restricts components such as Enterprise JavaBeans from creating threads. This restriction means that if your service provider needs to create threads, then it should do so inside of a doPrivileged block. This allows the component's container to grant permission to the service provider for thread creation without granting the permission to the component.

Here is an example of a utility method for performing the thread creation inside of a doPrivileged block.

private Thread createThread(final Runnable r) {
    return (Thread) AccessController.doPrivileged(
        new PrivilegedAction() {
            public Object run() {
  	        return new Thread(r);
	    }
	}
    );
}

The Ground Rules