This question is mainly directed at the authors and maintainers of the
EJB1.1 specification (hi, Mark).
The specification does not allow EJBs to use synchronization primitives
or to create threads of their own. This list has also implied that this
means that an EJB cannot call another piece of code which might create a
new thread internally.
Question #1: Is this latter implication indeed true?
Question #2: Consider the following scenario:
// inside bean class
public void someBusinessMethod() {
// delegate to third party product that provides this
// functionality:
Frobnicator frobnicator = FrobnicatorFactory.getFrobnicator();
frobnicator.someBusinessMethodImplementation();
}
What if frobnicator.someBusinessMethodImplementation() (last line above)
results in a new thread being spawned to perform the work? May this be
legally blocked by an EJB1.1-compliant container? If so, how will it be
blocked? Will a SecurityException be thrown?
Question #3: Using the same scenario, what if
frobnicator.someBusinessMethodImplementation() performs a lot of work in
parallel via multiple threads, waits for them all to complete, and then
returns synchronously? (That is, what if at the termination of the
method the number of threads running in the VM is equivalent to the
number of threads running in the VM when the method was called? Does
this affect any restrictions (I'd guess not)?)
Question #4: The implication from all this seems to be that I must know
whether a third party product uses threads internally if I wish to call
it synchronously from an EJB. If a product does create threads, then it
seems that I am forbidden from calling it if I wish to be fully EJB 1.1
compliant. Doesn't this violate OO programming?
Cheers,
Laird
===========================================================================
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".
