Laird Nelson wrote:
> An enterprise bean may not use thread primitives. I take this to mean
> it cannot do this:
[...]
Correct. The EJB class should be loaded so that it does not have the
privileges needed to call thread primitives. Not all containers seem to
enforce this, but they should.
> ...but the specification seems to imply that it COULD do something like
> this--and I hope I can:
>
> ThreadDelegate td =
> new BasicJavaObjectThatUsesThreadsAndSynchronizationInternally();
> td.doWork(); // implementation works with threads
>
> Is this true? If for some reason it is NOT true, doesn't this mean I
> now have to know about implementation details of all the plain-Jane Java
> objects my enterprise bean might use? Wouldn't such a thing blow
> reusability out of the water?
No, unfortunately, no application code can create or manipulate threads
in the container. The only code that can do so is code that is closely
integrated with the container, which basically means only the specified
EJB/J2EE services provided by the container.
So, yes, you do need to know about any classes that your EJB code will
use. I'm not sure if this "blows reusability out of the water" or not,
but that's for you to judge. What it means is that for a class library
to be "compatible" with an EJB container, it needs to follow the same
programming restrictions that our application code must. So the class
library must be "certified" as "EJB compliant" - if we can use those
terms (no, there is no official certification that I'm aware of).
> If it IS true, then why can't an enterprise bean use threads directly,
> as the invocation of td.doWork() in the example above occurs in the
> enterprise bean's caller's thread anyhow?
Thread management needs to be under the container's control. One
simplistic reason for this is so that our application code can't create
a multitude of threads that adversely affect the container's ability to
deliver the services it needs to. The container may be managing its
own internal thread pool, and our threads may affect its ability to do
so. Obviously if we are careful with our threads we can largely avoid
most of these conflict-related problems.
Another reason for thread restrictions is that a thread in the container
may carry along a context with it. When we invoke an EJB method,
transaction and security contexts are established. As the thread of
control from the EJB method weaves its way through the container, it may
attempt to access a resource. At that point the container may need to
use the established context for the resource access. At least some
containers attach these contexts to the thread, perhaps through a hash
table that points the thread ID at another data structure. I'm not
saying this is the best way to do it, or that most containers do this,
but the point is that the spec leaves the container open to this option.
If we create a thread in the container using the normal facilities, our
threads will not have the context associated with it. If our threads
then attempt to access a resource, the container would not be able to
find the context and "bad stuff" might happen. Once again, we could
avoid these conflicts if the total call graph of the threads we create
never cross a boundary where the container needs to find a context (if
in fact the container implemented things in this way). Or, perhaps the
container implementation gives us a way to create threads using its own
facility that makes our new threads compatible with the container's
threads. Then we'd be good to go, but of course this would be a totally
non-standard, proprietary solution.
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.
Active agents are outside the realm of EJB's design. EJB is a passive,
synchronous architecture. If we want an active agent, we need to create
it outside the container and have it invoke the EJBs just like any other
external client. Maybe someday we'll have some sort of standard for
creating an active object that can be installed in a J2EE container, but
as far as I know there's nothing like this yet.
For parallel processing, we don't have many options. AFAIK, the best
option is to use JMS's message session pooling to process messages in
parallel. This assumes the container actually implements JMS of course.
Again, maybe someday we'll have some standard facilities for creating
and managing container-compatible threads, but not yet.
So, it's possible to do multi-threading in a container. I had a client
that did so. You need to make sure that the classes that create and
control the threads are loaded in such a way as to have the permissions
to do so. The threads need to behave themselves to avoid conflicting
with the container's threads, and to avoid any situations where the
thread's context may matter. But this is all non-standard and certainly
not recommended in general practice.
-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".
