> 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.
That would work for you, but someone else will want the thread to do
transactional updates directly. But there's not transactional context.
Someone will want to make sure the only some users can access the
threads, and security control on the bean is not enough.
The thread will open up a connection in an unknown transaction/security
context, when you need a transaction/security context to get stuff done.
The conclusion is, and see elsewhere on the list, that EJB just does not
offer enough APIs to really let you use threads with all the services
you might require. The API should address that by adding more
capabilities, not just saying "ok to threads".
> > 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.
Because an EJB server may perform operations that will cause your
threads to break. The EJB server has control over its threads, but not
over your thread. And it has no API for interacting with your thread to
help solve that matter. So the EJB server will prevent you from
starting/stopping threads if it cannot offer you such an API.
If EJB added ThreadBean than such a beast would get all the benefits of
EJB, plus allow the EJB server to work *with* your code, plus let you do
threads.
In my opinion, ThreadBean is doable, desireable and probably the best
fashion to implement such functionality, and I would sure like to see
such an extension to the API.
arkin
>
> >
> > 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
