Eric Williams:
> > The reaction is almost univerally the same... "bleagh" as
> > you put it.
>
> I say again: "Bleagh".
Let me say it too. "Bleagh". Also thanks for a nice post.
This discussion came up ages back either in the EJB round table
or this list (May 98, I think). I (being the implementor then
of the weblogic ejb package) was arguing for letting the programmer
create threads if s/he wanted to. My argument was that the system as
a whole should be scaleable, not the EJB server alone. If they
create threads on every call, that's their problem; as a vendor
I'm not going to feel responsible for it.
If they use "synchronized", it should be a noop. If it blocks,
there's a bug in the EJB server.
If they call other packages that might be doing thread related
stuff, let them.
>
> > But I think the longer you work with EJB, the more you grok why these
> > restrictions
> > are in place and the more you come to think that the EJB specification
> > writers
> > did the right thing.
The only real problem with creating threads yourself is that
transaction and security context cannot be propagated. My opinion
is that this should be documented as a caveat and left alone.
> > An EJB server *has* to be able to control its
> > environment,
> > to include all resource utilization. Stability, security, and
> > scalability demand
> > it.
I don't buy this argument . There are any number of ways in which
you can mess up stability and scaleability. Do you prevent beans
from calling System.exit()? Do you prevent people from creating
200000 JDBC statements when one would suffice? Do you prevent
people from writing a deadlock using 3rd party products?
The EJB server doesn't have control.
It is up to the application implementor to create a solution
that has all the properties; one subsystem alone cannot do
everything. It is exactly in the same spirit as the ACID
properties of a transactional system. "C" for "Consistency" is
not given to you by a database alone: The system as a whole
offers this property to say, a user withdrawing money at an
ATM.
> But it is then incumbent upon the spec. writers to write the spec. in
> such a way that perhaps this is one *option*. Alternatively, if the
> ....
> .. Much good stuff elided.
>
> 1. Use anything in the java.io package.
> 2. Do anything or call anything that might at some point in the call
> stack result in new Thread().
> 2a. Of course this means that I must know the internal details of
> every third party piece of software that my EJBs might call.
> 2b. This of course violates everything you know about encapsulation.
> 3. Publish messages using JMS (since that might result in a new Thread()
> call).
> 4. Accept user input (no blocking IO calls)
>
> Did I miss anything? Or misstate anything?
Nope. I think the spec got this dead wrong.
Which is why:
<Vendor>
The weblogic server does not limit you artificially in this respect.
</vendor>
-Sriram
===========================================================================
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".
