Rickard Öberg wrote:
> > Do the standard EJB restrictions (no thread activity, no IO) apply also to
> > non-EJB classes used by the EJB?
>
> Yes.
Agreed.
> > For example, suppose I have EJBBean A (either BMP or CMP) and util
class U.
> >
> > Inside A's methods on the remote & home interfaces, A instantiates a U and
> > calls methods on it.
> >
> > Must the U methods (executed in the EJBserver JVM) also abide by the EJB
> > restrictions, or are they free of these constraints?
>
> Yes. The important thing is that they have the same classloader. If you
> package U outside of the EJB-jar, and instantiate it outside of the bean
> (such as a RMI-object), then U does not need to abide to these
> restrictions.
I had never really considered the class loader as an issue. Would
you please explain a little more how being loaded by the same class
loader is important?
I think there are two important reasons for thread restrictions.
First, when a bean method is invoked, it carries along with it
security and transactional contexts. If this thread then accesses
resources, the contexts would be used to access the resource. Any
thread that we create in the bean would not have this context
attached to it, and if those threads went off and accessed
resources, security or transaction problems can arise. If the
container provided a means to create a thread that inherited the
context from the main invocation thread, it might work, but this
would be a vendor specific extension.
The second issue with threads is that the container is responsible
for maintaining its environment. Most (all?) containers have an
internal thread pool that limits the amount of concurrent activity
(and avoids thread create/destroy bugs in certain version of the
JVMs ;-). If we create threads on our own, it could upset the
environment that the container is trying to maintain. Again, the
container could provide a facility for obtaining threads from its
internal thread pool for our use, but that would be vendor specific.
I think there is at least one vendor working on such a facility.
Paul
===========================================================================
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".
