dan benanav wrote:
>
> > 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.
> >
>
> But don't client make calls to EJB components? What if the thread made calls to
> other EJB's as a client? Why would that interfere? What if it didn't make
> intercomponent calls then would it still be a problem? Can you be even more specific
> here and give a very concrete example? Even some code would be nice.
<concrete-example>
BeanA and BeanB are installed on the same server
client invokes methodA() on BeanA
methodA() on BeanA starts threadA
threadA.run() invokes methodB() on BeanB
server crashes because BeanB doesn't have the correct thread context
(some expected values in thread-local storage are missing)
</concrete-example>
> >
> > 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.
> >
>
> This still doesn't answer the question as to why.
Quite a few app. servers attach data to thread-local storage for
container-managed threads. User-managed threads will have missing
data, and some app. servers cannot cope with the missing data.
> >
> > 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
--
________________________________________________________________________________
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".
