Why are beans not allowed to create their own threads?

Richard Monson-Haefel

Enterprise beans exist inside a container at run time. The container is responsible for managing every aspect of the enterprise bean's life including: transactions, access control, persistence, resource pooling, etc. In order for the container to manage the runtime environment of a bean, it must have complete control over the threads that access and run within a bean. This means that beans can not start or manage their own threads. Containers deny enterprise beans the privilege to manage threads for three basic reasons: Resource management, security, and thread-sensitive storage.

Resource Management
Containers manage every aspect of the runtime environment used by enterprise beans including transactions, access control, life cycle, resource connections, VM security, class loading, and threads. This allows the container to conserve as many resources as possible, which is important when there are hundreds of enterprise beans servicing thousands of clients. Without strict management of resources like memory and threads, EJB systems might consume to many resources (memory and cycles), which would result in a slow system, a prospect that is untenable in a high-transaction environment. Threads started and managed by enterprise beans would not be managed by the container, which would make it difficult to conserve resources.

There is no way for a container system to know in advance that a bean's use of threads is benign. While intentions may be sincere it is possible -- probably inevitable -- that developers would create malignant beans that spawn so many threads that the entire system slows down. One bean instance's misuse of threads or the commutative effect of many instances could cause a system slowdown. This is an insurgent denial of service, where the beans themselves sabotage a system's ability to respond to client requests. Security is a very good reason for denying bean's the privilege of starting and managing their own threads.

Thread-Specific Storage
Thread-Specific Storage (TSS) is an established and common technique employed by vendors to propagate and track client requests through the container system. It involves associating data with a thread. The data may be information about the client's identity, the transaction context, and other information, which can be accessed by any part of the container without having to pass the data explicitly. This is especially useful when enterprise beans invoke other enterprise beans or access resources, because it provides a convenient and transparent mechanism for transferring information about the who is making the request and under what circumstances. Each vendor will use the TSS technique differently according to the mechanics of their server. Threads started and managed by the enterprise bean explicitly would not have the proper TSS -- that would require intimate knowledge and access to the vendors container system. Without the right TSS the enterprise bean's threads can not operate within the container system properly. This is another reason why bean are not allowed to start and manage their own threads, it would short-circuit the vendor's use of TSS.

Related FAQs: