"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 just learning this myself, so take this with a grain of salt.
Additionally I'm not familiar with WebLogic (yet; I have to be soon
:-)).
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.
If you really need to spawn your own threads, minimize your use of EJBs
entirely. Make your EJB client be a regular Java bean itself that
perhaps spawns a thread and calls through to a session bean or an entity
bean. Yes, this is more code to write, yes it's another layer whose
only purpose is to work around EJB limitations, and yes it's irritating,
and yes you should be able to just do this inside an EJB if it is truly
supposed to be a distributed component, but no, you can't. :-)
Hope that helps.
Cheers,
Laird
===========================================================================
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".
