dan benanav wrote:
>
> I have been reading this Threads question thread and I still don't completely
> understand why creation of threads would damage the container's "management" of
> threads and resources and why it is restricted. I understand somewhat why it
> is usually a bad idea to spawn threads in method calls (see below) but maybe
> there are circumstances in which it is not bad It would be very helpful if
> someone could give a very concrete example of why the spawning of threads is
> not good. I keep hearing things like "a container needs to manage threads and
> resources". How does it do that? What kinds of things does it do to manage
> threads? What damage would be done if I create a thread? Please be as specific
> as you can and give concrete examples of what the container does to manage
> threads.
Dan,
Some EJB servers attach various pieces of context information to threads they
create (lets call them contained-managed threads). A user-managed thread will
not have any of the required context information (not necessarily just
transaction and security context), and thereby if the user-managed thread
attempts to interact with the server/container (e.g. make an intercomponent
call), it is possible that the server/container will crash, since it is
perfectly valid for a server/container to ASSUME that any thread making an
intercomponent call is a container-managed thread with the correct context.
Since the spec specifically disallows EJB components from creating threads,
some app. servers may be architected in such a way that thread creation is
not permitted, or is restricted in some way.
So I see two possible general problem areas with EJBs that create threads:
(1) The server/container doesn't implement support for threads at all, which is
legal although many would argue is not very nice.
(2) The server/container allows EJBs to create threads, but places restrictions
on what can be done by user-managed threads.
One way this could be addressed is by requiring the EJB server/container to
provide a ThreadManager, e.g.
package javax.ejb;
interface EJBThread extends javax.ejb.EJBObject
{
void run();
};
interface ThreadManager
{
void start(EJBThread thread);
};
The idea of the above is that instead of using "new Thread(...)" to create
new threads, you would delegate to a ThreadManager object that is provided
by the server/container (perhaps it could be looked up via JNDI). Then any
EJB object that implements the EJBThread interface could be started running
in a new container-managed thread.
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
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".
