Richard,
Writing any type of server software requires you to adopt some sort of
discipline in how you use resources (e.g. threads). With any non-trivial
project you would want to avoid mixing thread management with your business
logic. The advantage of EJB lies in the discipline that it promotes and
enforces. Using EJB you can focus on your business logic while not being
dragged down by how to manage your resources.
Specifically, you don't have to worry about creating and managing threads
(since your software is intended to be used with multiple clients,
multi-threading is critical). This also means that you don't have to
synchronize threads. Since you don't synchronize, you don't need to lock
objects and deadlock is a non-issue inside your business methods. In one
word, complexity that any server developer would have to very carefully
implement is completely eliminated from your code.
The EJB server manages (pools) and synchronizes threads for you, locks
shared objects when it is necessary and even detects deadlocks. If you were
allowed to create your own threads, the server would not be able to assist
you with the above. In other words, a simple change in your business code
could suddenly start to hang (deadlock) your server in hard to reproduce
ways. That is when you need the most support, and the server would not be
able to tell you a thing. It would also be extremely difficult to maintain
the code. Understanding and debugging multi-threaded code is one of the
hardest jobs out there :-)
Of course, as with any discipline, EJB comes with its disadvantages. Until
there is a sound and generic mechanism to manage threads, locks and detect
deadlocks, the restriction imposed by EJB is acceptable in order to write
reliable and maintainable servers quickly.
Imre Kifor
Valto Systems
-----Original Message-----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, March 12, 1999 2:13 PM
Subject: Re: Modeling an application with parallelism using EJB (reply)
>Imre,
>
>Can you expand on the below paragraph and explain why we don't do
>multi-threading in EJB and why multi-threading would eliminate EJB's
>advantage.
>
>Thanks,
>
>Richard
>
>
>-----Original Message-----
>Imre Kifor wrote;
>
>As others have said it already, the EJB model does not allow you to
>spawn threads in your beans. There are very well founded reasons for that
>and lifting the restrictions would eliminate all the advantages of EJB
>itself.
>
>===========================================================================
>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".
>
>
===========================================================================
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".
