You should avoid spawining threads. The spec prohibits it. No EJB Server enforces the spec completely, thank god. You can launch threads in both JBoss and Orion, with no problem. Context information is usually kept as a field within the thread's implementation(this is usual in TP altogether; MTS does this, in fact, all TP systems I've worked with do this).
Sometimes real life work cannot afford to comply fully to the spec. Since people have already stated what's in the spec(the easy part, why am I always asleep when you can give the simple answers? ;-) let's ask ourselves WHY?! Why does the spec prohibit spawining threads? (all I can think of right now) 1) If you'd want to keep transactional capabilities, it makes transactions asynchronous(System.unleashHellOnEarth(); ), not to mention most TP systems have their own specialized version of thread that is required in order to track activities. 2) The spec attempts to conceal difficult problems such as thread management, synchronization and others from EJB users. That allows for widespread adoption of J2EE(you don't need to know what a critical section is to code EJBs) 3) Prohibiting launching threads instead of forcing EJB-Container implementors to elliminate the possibility makes it easier to build EJB-Servers. 4) Native code servers(CORBA servers supporting EJBs, like old OAS from Oracle) don't support spawining threads at all, so it's definetily not portable. What could you expect if you launch threads in an application? (again, all I can think of right now) 1) The most usual will be that the spawned thread doesn't execute in the same transactional context, tough it might control NEW transactions by obtaining a UserTransaction like any other regular client. 2) Trying to make the spawned thread vote in the original transaction will need some synchronization framework. It will be more than difficult if not impossible in some servers to be able to pull this off before transactions are eliminated because they're suspect of being deadlock. On the same topic, you'd also probably will need to stretch the TX timeout for your application/server. This usually leads to lots of deployment/maintenance problems. Why shouldn't you use Runtime.exec()? (yet again all I can think of) 1) Spawns threads (but if the operations aren't transactional nor they need any other transactional attributes like security, etc. then who cares?) 2) You're using a process or function that's not part of Java; this means, you lose strong-type checking, Exception handling, write once run anywhere, etc. (Then again, you might not need it) That's all I can come up with, maybe somebody cares to complement/rebate? I've launched threads on my applications, in fact, you may do so from Servlets/JSPs (_that_ spec doesn't prohibit it). There are some maintenance tasks that I perform asychronously from threads; I think I could probably have coded some kind of client that continually hits a web page to perform them, but that would also had sprung other problems, mostly post-delivery. My point is there are such times in which spawining a thread IS the optimal solution. I hope this provides more information to identify which ARE and AREN'T the times when you should venture. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Endres > Sent: Tuesday, July 23, 2002 2:56 PM > To: [EMAIL PROTECTED] > Subject: Re: Is Exec() allowed in EJB > > > You should never spawn threads. Ergo, you should not call exec(). tim. > > > Thanks for the reply. On the same lines, do you think it is ok to > > spawn java threads in helper classes that are used by the > EJB? Please > > note that the helper classes are part of the same "jar" > that contains > > the EJB. > > > > To re-state, what I want to know is this: The spec doesn't allow > > spawning threads from the bean classes, but is is it okay to use > > "synchronization" primitive and to spawn threads from the helper > > classes that are used by the beans? > > > > Thanks. > > > > Venki > > > > ----- Original Message ----- > > From: "Sven E. van ?t Veer" <[EMAIL PROTECTED]> > > To: "Venki" <[EMAIL PROTECTED]> > > Sent: Tuesday, July 23, 2002 8:35 AM > > Subject: RE: Is Exec() allowed in EJB > > > > > > > FAIK, The ERB spec does not allow this. I see no reason > however that > > helper > > > classes cannot do this. > > > > > > -----Original Message----- > > > From: A mailing list for Enterprise JavaBeans development > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Venki > > > Sent: Tuesday, July 23, 2002 9:05 AM > > > To: [EMAIL PROTECTED] > > > Subject: Fwd: Is Exec() allowed in EJB > > > > > > > > > I am resending the message as I the email that I sent earlier > > > bounced back. I apologize for any inconvenience. > > > > > > ==========================Forwarded > > > message========================== > > > > > > > > > Hi, > > > I have implemented a stateless session bean that calls a helper > > > class. I am spawn a process from a method in the helper > class using > > > runtime.exec(). > > > Given that spawning threads is not allowed in the EJB server > > environment. > > > Is spawning processes okay? Is it not equivalent to > spawning threads > > > which are nothing but light weight processes? > > > I need answers quite urgently. If anybody has > experience in this > > > pls do let me know. Thanks. > > > > > > Venki > > > > > > ----- End forwarded message ----- > > > > > > > > > ====================================================================== > > ===== > > > 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". > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > > > ====================================================================== > > ===== > > 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". > =========================================================================== 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".
