Although conflict with the container is one of the reasons why EJBs are not allowed
to create threads, there is a more important reason.
A major objective of EJB is to achieve the creation of a multi-user service by
implementing single threaded components. Writing robust, multi-threaded code is hard
and eliminating the requiring that this skill to be mastered in order to implement a
middle-tier service is one of the main benefits of EJB.
The goal is to delegate all responsibility for managing concurrency to a container
and its resources (DBMSs, etc). EJB 1.1 succeeds in doing this for many types of
applications. EJB 2.0 will significantly expand the EJB app domain by adding support
for asynchronous invocation (JMS integration).
So, the question is not what you can do within your container it is what your
container can do for you :>). Why should you be worrying about creating threads if
you can get the container to handle all of that complexity?
Evan Ireland wrote:
> 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".
===========================================================================
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".
