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