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
"Herbers, Joe" wrote:
> Let's assume that we can't use JMS. WebLogic has the concept of a startup
> class - a regular java class (non-bean) that is started up by the server.
> What if we create a startup class that can accept reuqests, spawn a
thread,
> and return. In this thread, we would class the beans that we are needed
to
> perform the tasks. Thus the clients don't have to wait for the app to
fully
> process (our objective), tasks go on in parallel, and we haven't violated
> the EJB threading policy.
>
> Does this make sense? Is there a better approach?
I'm not sure what you mean by "class the beans" above, but I'm going to
guess that what you're talking about won't work and be spec. compliant.
===========================================================================
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".
