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".
