Hi,
Below is a complete answer to this question that is taken from the jGuru EJB
FAQ, which I hope will provide you with the an insight as to why beans can not
start and manage their own threads. The FAQ entry can be seen at:
http://www.jguru.com/jguru/faq/view.jsp?EID=15893 . The rest of the EJB FAQs
are at http://www.jguru.com/faq/EJB
***************
QUESTION: Why are are beans not allowed to create their own threads?
ANSWER:
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.
Security:
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
savatage a systems 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:
<a href=" http://www.jguru.com/jguru/faq/view.jsp?EID=14648 ">Can I use Threads
in an enterprise bean?</a>
<a href=" http://www.jguru.com/jguru/faq/view.jsp?EID=9876">What is a
container?</a>
*****************************************
Laird Nelson wrote:
> An enterprise bean may not use thread primitives. I take this to mean
> it cannot do this:
>
> Thread t = new Thread(someRunnable);
> t.start();
>
> ...or this:
>
> synchronized (someGuard) {
> doCriticalWork();
> doMoreCriticalWork();
> }
>
> ...or this:
>
> Thread t = new Thread(someRunnable);
> t.start();
> t.join();
>
> ...but the specification seems to imply that it COULD do something like
> this--and I hope I can:
>
> ThreadDelegate td =
> new BasicJavaObjectThatUsesThreadsAndSynchronizationInternally();
> td.doWork(); // implementation works with threads
>
> Is this true? If for some reason it is NOT true, doesn't this mean I
> now have to know about implementation details of all the plain-Jane Java
> objects my enterprise bean might use? Wouldn't such a thing blow
> reusability out of the water?
>
> If it IS true, then why can't an enterprise bean use threads directly,
> as the invocation of td.doWork() in the example above occurs in the
> enterprise bean's caller's thread anyhow?
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
EJB FAQ
http://www.jguru.com/faq/EJB
EJBNow.com
http://www.ejbnow.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
