Legally Starting Threads/Synchronizing EJBs - Hell Or Heaven 📎
With Bean Managed Concurrency demarcation, the container allows full concurrent access to the Singleton bean instance. It is the responsibility of the bean developer to guard its state as necessary against synchronization errors due to concurrent access. The bean developer is permitted to use the Java language level synchronization primitives such as synchronized and volatile for this purpose. [EJB 3.1 spec, page 111]You only need to apply an additional annotation on a @Singleton and do whatever you want - at least synchronization-wise:
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class InefficientHelloWorld {
//AtomicInteger would be a lot better.
private static volatile int counter = 0;
//synchronized just for demo purposes, o.k with CMT.Bean.
public synchronized void sayHello(){
new Thread(new Runnable() { //still not allowed - but it works
public void run() {
//out.println is not a best practice either...
System.out.println("Hello World: " + counter++);
}
}).start();
}
}
In the majority of all cases it is better to use just @Stateless beans and just let the container manage threads and synchronization for you. @Asynchronous is far better and easier to use , than the example above.
The "working" example was pushed into http://kenai.com/projects/javaee-patterns/. The name of the project is "BeanManagedConcurrency". Starting and managing threads in the application code is hard to implement, monitor and debug - it is by no means a best practice. [See Lightweight Asynchronous Facade pattern, page 65 in "Real World Java EE Patterns Rethinking Best Practices" book for more in-depth discussion]