> I think we'll have to agree to disagree on all these points. I tend to
> be a heck of a lot more trusting of the programmer. I don't like to be
> policed myself, nor do I force it on anyone. There are very practical
> transaction processing monitors that are eminently useful and not
> paranoid about what a programmer could do: Tuxedo, CICS and Encina.
I am aware of these, and also of the capabilities of the JTA API. The
main difference which was already pointed on the list is that Encina,
CICS, Tuxedo all expose enough APIs for you to get the job done (i.e.
use threads), while EJB exposes only a subset of the API which is
insufficient.
It's not so much a manner of are threads good or bad, but whether EJB
has sufficient APIs to let you benefit from EJB + threads. It doesn't,
and in my opinion that should be corrected.
> Sure there are exceptions; allowing an admin to limit the maximum
> number of database connections (not statements) and to throttle
> incoming connections if the server is loaded, implementing checked
> transaction behavior, etc. These are problems that one typically sees
Actually all that works pretty well if you're using JTA and bypassing
EJB, and we have people using the transaction monitor directly and
playing around with threads all day long. No problem. But they can't do
it through EJB, and those that do not care about EJB to begin with, get
that extra functionality which is already there.
> in practice and have been plugged on a case by case basis. My opinion
> is that there's no need to get paranoid about what a programmer could
> do. It doesn't help anyone and it limits creativity and performance.
> 99% of programmers are neither malicious nor complete idiots; they may
> design something wrong and will learn soon enough not to do it.
My experience. Developers (including myself, nothing like first hand
experience) have good intentions. They develop something that runs very
well in the lab and passes all the tests. They deploy it, and then
through lack of understanding of all the possible interactions (and EJB
is a nasty beast inside) at some point it fails in a production
environment.
When your server is down for five minutes during production, it's going
to cost you some money. With all good intentions, that is something
developers are trying to avoid.
The three main reasons why I would recommend using EJB to begin with are
the container management of the bean life cycle, the fact that the
container hides the TP monitor behind a nice API, and the WORA nature of
EJB.
Right now the behavior of threads is unspecified, does not have an API
to allow you to benefit from it, and is not part of the life cycle. That
means you can use threads, but you lose all three points.
Enabling Thread.start() is not a solution to either problems.
First, you have to specify the proper behavior so your EJB applications
retains WORA. Second, you need to add these APIs so your threads can
actually use transactions, connection pooling, security to their
advantage, not hang there in the dark.
Third, you can (in my opinion should) extend EJB to deal with thread
life cycle.
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".
