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]

Reply via email to