Charlie Alfred wrote:
> I'd appreciate it if you could point out where in the EJB 1.1 spec there's
> a specific statement that says that Java object methods called by an
> EJB must follow the same rules as the EJB.
I don't think we're going to find such a statement. The spec seems
to leave a lot unspecified in this area. It largely addresses just
the EJBs themselves. I'm not sure if it even mentions classes that
are packaged with the EJBs. Anyone?
The statements I made come from two places. First, I've been
following the discussions on this list and other EJB discussion
forums over the past months, which have come to these conclusions
(unless I'm misinterpreting the discussions). Second, I've dug
into a couple of EJB container implementations to see how they're
put together and to learn what some of the underlying issues are.
Perhaps I should have labelled my statements as "IMHO," but I don't
think they're very far off the conclusions reached on the list.
> Section 18.1.2 has two explicit prohibitions related to EJB's and threads:
>
> * An enterprise bean must not use thread synchronization primitives
> to synchronize execution of multiple instances.
>
> [Same reason as above. Synchronization would not work if the EJB
> Container distributed enterprise bean instances across several
JVMs.]
>
> * The enterprise bean must not attempt to manage threads. The
enterprise
> bean must not attempt to start, stop, suspend or resume a
thread; or to
> change a thread's priority or name. The enterprise bean must not
> attempt to manage thread groups.
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?
> > 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?
> It's also been my experience that some vendors are more lenient in this
> area than others. I have a proof of concept demo in WLS that packages
> in the same jar, enterprise beans and multi-threaded JMS helper classes.
> I suspect that this is not going to be portable, but right now for the
> application I'm working on, portability takes a back seat to asynchronous
> messaging. For another set of EJB's, portability is the driving factor
> and it's appropriate to take a conservative stance when interpreting the
> spec.
I had a client that also implemented multi-threading within the
WebLogic 4.5.0 container, and it worked for them. WebLogic seems
to implement a liberal version of the security permissions listed
in section 18.2.1.1 of the spec. The spec says that the container
"should" deny permissions, but not "must" deny them. If another
container implements a strict version of the permissions, then
this code may not run in that container.
In many cases, most of the EJB programming restrictions can be
worked around (or even ignored), depending on the container. As
you mentioned, if portability is a goal this may not be a good
tactic, but it works a lot of the time.
> In any case, I hope that the EJB 2.0 spec clarifies things in this area.
I've been told they are working on it, but I guess we'll have to
wait and see what comes out in the 2.0 spec.
-Paul Hodgetts
===========================================================================
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".
