Is it still the case, given the JDK 1.5 concurrency stuff, that you are still not technically allowed to spawn threads in a J2EE container (per spec guidelines)? Did the latest J2EE spec loosen that restriction maybe?
Ignoring for the moment the fact that we all do it and have been for a long time :) I've said for a lone time that there are some problems that can't really be solved any other way, so whether you're *supposed* to do it or not is irrelevant, you just have to be careful and be aware of the gotchas to watch out for, as Jeremy points out. Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog On Tue, July 29, 2008 1:09 am, Jeromy Evans wrote: > > If you're using Java 1.5+, the standard concurrent package provides > everything you need. > > http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html#package_description > > There should be several tutorial available for it and it's well with > understanding the various approaches. Prior to Java 1.5 there is a > library available that the concurrent package was derived from (I forget > the name). > > Important: If you're creating your own threads within a container, it's > essential that you guarantee that the threads and their resources are > properly released. Failing to do so will prevent the container from > undeploying your application or shutting down cleanly. One technique to > assist with this is create your ExecutorService within a > ServletContextListener that uses the shutdown method to shutdown the > threads and release all resources. Another approach is to use a library > that provides this level of integration already (such as is available in > one of the Spring packages I believe). > > regards, > Jeromy Evans > > [EMAIL PROTECTED] wrote: >> Hi Dave, >> >> You can just create any class that extends the Thread object or >> implements the runnable interface. The required method, run(), should >> abstract what u want to do, (connect to the 3rd party server). >> Instantiate that class then call its start() method from the Struts >> action that should trigger it. Your action should finish safely without >> waiting for that thread to finish. Note: this is just a bare >> implementation, you might want to consider using thread pooling to >> manage your resources. What exactly do you intend to do? Will you wait >> for a response from your HTTPS server? >> >> Reginald Javier >> Software Engineer II, Strategic Customer Solutions Implementation >> T: +632-859-5442 >> -----Original Message----- >> From: dave.smith [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 28, 2008 11:45 PM >> To: user@struts.apache.org >> Subject: Re: Background Threads >> >> >> I forgot to mention that I am using Struts 1.1. >> >> >> dave.smith wrote: >> >>> I have a function that POSTs data to a third party HTTPS server: void >>> postData(String sURL, String sData); >>> >>> I need to call this function as a background thread from an Action >>> class, >>> so that the user doesn't have to wait on the connection to establish. >>> How >>> can I safely call this function so that it becomes a background thread? >>> >>> Thanks, >>> Dave >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Background-Threads-tp18691709p18691741.html >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.138 / Virus Database: 270.5.6/1578 - Release Date: >> 28/07/2008 5:13 PM >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]