> Paul Hodgetts wrote:
>
>
> 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.
>
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.
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.
> 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.
>
<snip>
> -Paul Hodgetts
>
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.
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.
In any case, I hope that the EJB 2.0 spec clarifies things in this area.
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".
