All the examples I have seen from this list have been using a strange logic. The logic
is that one can get into trouble if you use threads and that is why EJB does not allow
threads. Using the same argument I can conclude that threads should not be built into
the Java language. The following example illustrates this point.
Thread A calls a synchronized method in Thread B which then makes a call to a
synchronized method in Thread A. This leads to a deadlock situation. Therefore
threads
should not be used, nor for that matter should "synchronized" methods be used.
The examples presented lead me to conclude that there are certain things one should
not
do in a thread created from a bean. For example one should not use the context of the
parent thread to find homes etc.. But what if the thread got its own context, just
like
a typical client. Surely when I create a context in the client that thread is not
associated with any thread that the container is managing. What would be wrong with
that?
For example,
public void run()
{
Context ctx = new IntialContext();
AHome home = (AHome)narrow(ctx.lookup("whatever"), AHome.class);
ABean bean = home.findByPrimaryKey(1);
}
Now the thread is behaving just like a client. Can someone tell me what would be wrong
with that?
An argument that might make some sense is something like the following:
A container needs to keep track of the number of threads it creates in order to
determine how many instances of beans that it should create. If a user is allowed to
create threads this may affect the number of bean instances the container created to
manage call to entity bean objects. (I don't know if this really makes sense but it
would be a good argument).
Alternatively one could argue that allowing a bean to create it's own thread would make
it impossible to enforce certain security requirements. If this argument is to be made
I would like to see some concrete examples.
So I would still like to see better and more clear arguments here. Most likely those
arguments should argue about the containers responsibilities and why it would not be
able to meet those responsibilities if thread creation where allowed.
Mark Hapner wrote:
> 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".
===========================================================================
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".
