Paul Hodgetts wrote:
> And the next statement says:
>
> "These functions are reserved for the EJB Container. Allowing the
> enterprise bean to manage threads would decrease the Container's
> ability to properly manage the runtime environment."
>
> Wouldn't it follow from this that managing threads from a non-EJB
> class would also decrease the container's ability to manage the
> runtime environment?
>
> These specifications don't go into very much detail. But I think
> if we dig a little deeper to understand why these restrictions might
> be put in place, we can draw some inferences to non-EJB application
> classes. I listed some of the more detailed reasons in my previous
> post, and Richard Monson-Haefel posted an excellent list as well. I
> think it's reasonable to infer that non-EJB application classes would
> create the same problems in these areas that EJB classes would. But
> again, the spec is vague in this area, and these are my conclusions.
>
> What is your conclusion?
>
It depends on what we mean by the container's run-time environment.
The EJB 1.1 spec describes an EJB server, EJB container, and
enterprise beans. This yields 4 API's:
1. Client interaction with EJB Server (authentication, JNDI, JTA, etc.)
2. Client interaction with EJB Container (home and remote interfaces)
3. EJB Container interaction with enterprise bean
4. EJB Container interaction with EJB Server
Items #2 and #3 are the most well defined in EJB 1.1. Item #4 is not
specified at all, and item #1 is partially defined.
My conclusion is that the container's "run-time environment" includes those
actions that are necessary for authorization, bean life-cycle management,
and transaction-consistent persistent storage. In other words, I see the
container's run-time environment as being different than the server's (although
the spec is vague enough to leave lots of room for interpretation).
In my view, a distributed event logging service shouldn't fall under the
umbrella of the container's run-time environment, even though it might be
called from an enterprise bean. The reason is that the events being logged are
intended to be separate from the enterprise bean's transaction (i.e. recording
data about when the transaction occurred and what its outcome was).
The verdict for a JMS listener isn't as clear. On one hand, I see utility
in allowing a JMS listener to run in its own thread within the EJB Server.
When a message is received, it acts as an EJB client and invokes the
appropriate method on the home/remote interface. This thread is not
interfering with the container's run-time environment because it is on the
front-end of it. On the other hand, this approach forfeits the security
and transaction context of its caller, in order to permit an asynchronous
messaging protocol.
> > > I think that there's two main reasons for wanting to create threads in
> > > a container. The first is to create an active agent of some sort. The
> > > second is to utilize parallel processing.
> >
> > There are a few other reasons. One has to do using JMS with EJB's
> > (for those Server vendors which have already implemented this in advance
> > of EJB 2.0). JMS Message Sessions require serialized access, but the
> > JMS spec doesn't require them to provide the mechanism for this on the
> > sender side. Another has to do with distributed event logging services.
>
> Sure, but if you're creating a thread that manages a queue,
> you're creating an active object. If you're using the queue as
> a synchronization point for multiple threads, you're managing
> parallel processing. Or is there some other fundamental reason
> behind the threads that I'm not understanding?
>
No. I just assumed a narrower definition of "parallel processing" (e.g.
taking a single complex operation, like a graph traversal, and partitioning
it into pieces that can run at the same time). By definition, the broader
definition covers all possible uses of threads on its own, since threads
exist to provide a lightweight form of parallel processing within a single
virtual address space. :-)
Charlie
===========================================================================
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".
