I agree with your point of view !!!
But, in most cases we use EJB like a transactional monitor, but in some
special cases we can have several
modules (A module can be an EJB, a thread/process, a simple class, a
service or something else) and theses modules
should be able to manage the transaction, to exchange / share transactional
context.
In some case, we need transactional context that is decoupled of the EJB !
By example, in the AS we can have a set of thread,
each thread has its own purpose and transactional context. Example: each
thread can read a file to insert tuple in a DB or create others EJB, or
....
Of course, this EJB is not a BO, it is more a technical component that run
under a container !!!
EJB is not done for this, of course, some AS have startup class that are
able to have their own transactional context, ....
But until now EJB are not done for this !!!
Maybe it is a special case and maybe it is not a good practice, but if we
need a portable solution, I think that having an EJB without transactional
context
is sometime usefull. We manage the transactional context and so we can have
several threads.
Of course, we can have portable startup class by using JMX / MBean, but
until now JMX is not implemented on every AS !
Otherwise, I completely agree with you !
Dave, maybe I m wrong, but I m interested about your point of view !
Christophe
Dave Wolf
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
> cc:
Sent by: A Subject: Re: Threading delegate in EJB
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@jav
a.sun.com>
02/09/01 01:36 AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
> 1 - In the EJB specification : you cannot have threads in EJB !!!!
>
> 2 - Why ?
>
> Hum, for some purpose, it is stupid, because in some case we want to have
> several transactional context and parellel processing in EJB !!!!
> But it is not a good practice.
I disagree it is not stupid.
(a) How do you intend in this multithreaded environment to maintain
declarative transactional contexts?
(b) How do you intend to maintain a quality of service for this
transactional work without building a significant amount of framework
(c) The role played by application containers and J2EE is that of allowing
developers to develop business logic and not writing thread safe re-entrant
code.
> 3 - What you can do ?
>
> I think that EJB are good for e-commerce, with high transactional context
> between client and server, but If you want to manage another
transactional
> context and access to DB, create a simple JDBC connection, or create
> another connection pool ! Or reuse your connection pool to get a new
> connection
> and work with that.
If you want parallel processing of components and you want this done in a
transactionally aware fashion you should investiagte the use of messaging
systems like JMS and the EJB 2.0 Message Driven Beans which allow you to
create logical threads while maintining declarative transaction contexts
and
thus avoidingin the risk in trying to implement your own multi-threaded
re-entrant code.
Dave Wolf
Internet Applications Division
Sybase
>
> Take a look at castor.exolab.com which is a JDO (Not compatible with SUN
> JSR, but sometimes better).
>
> Hope it help
>
> Christophe
>
>
>
>
> "Sampathkumaran,
> Ramkumar (CTS)" To:
[EMAIL PROTECTED]
> <[EMAIL PROTECTED] cc:
> IZANT.COM> Subject: Threading
delegate in EJB
> Sent by: A mailing
> list for
> Enterprise
> JavaBeans
> development
> <EJB-INTEREST@java
> .sun.com>
>
>
> 02/08/01 08:18 AM
> Please respond to
> A mailing list for
> Enterprise
> JavaBeans
> development
>
>
>
>
>
> Hi,
> I would like to know whether threading can be done by a normal class in a
> EJB server which will be called by a bean.
>
> For eg: I have to retrieve around 2000 rows each from 10 different tables
> and aggregate them and send it to the client.
> So instead of sequentially accessing each table, can i write a class A
> which
> implements Runnable and spawns ten threads for acessing each table and
> aggregating the values(to be passed to the bean which will pass it to the
> client)?
>
> Does this violate the EJB specs or is an acceptable workaround?
>
>
> Regards,
> Ramkumar
>
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on this
> e-mail is strictly
> prohibited and may be unlawful.
>
> Visit us at http://www.cognizant.com
>
>
===========================================================================
> 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".
>
>
===========================================================================
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".
