Thread management and the Spring Framework

Do not use a scenario that can create unmanaged threads, for the following reasons:

• The application server does not recognize unmanaged threads.
• Unmanaged threads do not have access to Java™ EE contextual information.
• Unmanaged threads can use resources without being monitored by the application server.
• Unmanaged threads can adversely affect application server functions such as shutting down gracefully or recovering resources from failure.
• An administrator cannot control the number of unmanaged threads or their use of resources.

The following scenarios are examples of Spring Framework scenarios to avoid:

• registerShutdownHook

  Avoid using the Spring Framework AbstractApplicationContext class and its subclasses. These classes include the public method registerShutdownHook, which creates a thread and registers it with the Java virtual machine (JVM) to run at shutdown to close the application context. As an alternative, an application can use the lifecycle notices that it receives from the application server container to call the close method explicitly on the application context.

• WeakReferenceMonitor

  The Spring Framework provides convenience classes for simplified development of EJB components. However, these convenience classes spawn off an unmanaged thread that WeakReferenceMonitor object uses for cleanup.

You can use the Java Naming and Directory Interface (JNDI) name of the configured work manager as a workManagerName property to define a WorkManagerTaskExecutor instance in the Spring configuration file. The following example uses the JNDI name of the DefaultWorkManager in the application server, that is, wm/default:

<bean id="myTaskExecutor" 
  class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
  <property name="workManagerName" value="wm/default" />
</bean>