> 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.
Question. Let's assume a method call gets into an infinite loop and the
EJB container is interested in terminating the thread (Thread.stop()).
It should certainly be capable of doing that, in my opinion. If you want
to start a new thread, just use a container API to do that (nothing
wrong with EJB adding that).
> If they use "synchronized", it should be a noop. If it blocks,
> there's a bug in the EJB server.
The EJB server has control over the order of method calls, without
understanding what your code does inside. It may attempt to synchronize
method calls (as it should), but still perform method calls in such a
fashion that will cause the EJB code to deadlock.
(In fact, I believe I heard of that problem from someone using WebLogic)
> 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.
If you're going to add thread support, you have to address both
transaction and security. You can foretell what messages will be sent to
this list if you do not.
> 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
Yes. It throws a SecurityException.
> 200000 JDBC statements when one would suffice? Do you prevent
No, but if a bean takes forever to execute you can terminate it :-)
> people from writing a deadlock using 3rd party products?
No, neither do you prevent them from writing bad code. But you try to
help them in a manner that is most efficient.
The EJB specs seems to be in compliance with every bit of experience I
have with TP monitoring systems.
> The EJB server doesn't have control.
>
> Which is why:
> <Vendor>
> The weblogic server does not limit you artificially in this respect.
> </vendor>
Excellent.
Does it really work in production environment?
Is calling System.exit() from an EJB bean a documented practice?
arkin
>
> -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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
