Very simple answer. EJB can give you scalability and fail over by
managing threads (and other issues of component life cycle). To make
that happen you need to yield control to the EJB server.
If you are looking for asynchronous operations, JMS comes to the rescue
and adds these capabilities.
If you need to really mess with threads and object life cycles, then
yes, you have to depart from the EJB model.
You can't eat the cake...
arkin
Ron Yust wrote:
>
> Seems most solutions to the threads restriction is to use some architectural
> design that is outside the EJB container. That is understandable, but
> doesn't that also reduce the value of an EJB server? Now we have to
> replicate the scalability and failover capabilities in these other
> 'solutions'. I'm not seeing EJB as being easier when designing a complex
> enterprise application.
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Williams
> > Sent: Tuesday, February 22, 2000 11:26 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Threads question
> >
> >
> > To solve this type of problem, we have implemented a separate "workflow
> > server". When we want to start an asynchronous task, we write a new
> > workflow process record into the database. Periodically, the workflow
> > server polls the database for new jobs to execute. They workflow server
> > is not part of the EJB server, but workflow tasks can make calls back to
> > the EJB server if necessary. (We could have also used JMS to submit
> > new workflow jobs instead of a database w/ polling... but we haven't
> > committed to JMS yet.)
> >
> > -eric
> >
> >
> > "Herbers, Joe" wrote:
> > >
> > > What I meant to type below was "we would call the beans".
> > Sorry. The idea
> > > is that the startup class would do the thread spawning. JMS
> > may be a better
> > > solution for this and I will look into it.
> > >
> > > However, I also want to do parallel processing while I'm
> > performing these
> > > tasks in the server. To do a set of tasks in parallel within a
> > method is
> > > (relatively) easy with threads. JMS seems like overkill for
> > this because it
> > > adds overhead for coding, configuration and performance. But what other
> > > alternatives do I have?
> > >
> > > Again, maybe I should use a startup class - a method could accept the
> > > request, spawn off the threads, and wait for them to complete.
> > The threads
> > > would call the various session and entity beans to accomplish the tasks.
> > > Does this make sense??
> > >
> > > Joe
> > >
> >
> > ==================================================================
> > =========
> > 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".
--
----------------------------------------------------------------------
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".
