Menu
▾
▴
[Springframework-cvs] spring/docs/reference/src index.xml,1.72,1.73 scheduling.xml,1.14,1.15 taskexecutor.xml,1.1,NONE
|
From: Ben H. <ne...@us...> - 2006-04-20 18:51:43
|
Update of /cvsroot/springframework/spring/docs/reference/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30954/docs/reference/src Modified Files: index.xml scheduling.xml Removed Files: taskexecutor.xml Log Message: Combined Quartz, TimerTask, and TaskExecutor into one Scheduling section Index: index.xml =================================================================== RCS file: /cvsroot/springframework/spring/docs/reference/src/index.xml,v retrieving revision 1.72 retrieving revision 1.73 diff -C2 -d -r1.72 -r1.73 *** index.xml 20 Apr 2006 16:24:28 -0000 1.72 --- index.xml 20 Apr 2006 18:51:29 -0000 1.73 *************** *** 26,30 **** <!ENTITY mail SYSTEM "mail.xml"> <!ENTITY scheduling SYSTEM "scheduling.xml"> - <!ENTITY taskexecutor SYSTEM "taskexecutor.xml"> <!ENTITY testing SYSTEM "testing.xml"> <!ENTITY scripting SYSTEM "scripting.xml"> --- 26,29 ---- *************** *** 273,279 **** </listitem> <listitem> - <xref linkend="taskexecutor" /> - </listitem> - <listitem> <xref linkend="dynamic-language" /> </listitem> --- 272,275 ---- *************** *** 293,297 **** &mail; &scheduling; - &taskexecutor; &dynamic-languages; &testing; --- 289,292 ---- --- taskexecutor.xml DELETED --- Index: scheduling.xml =================================================================== RCS file: /cvsroot/springframework/spring/docs/reference/src/scheduling.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -d -r1.14 -r1.15 *** scheduling.xml 18 Apr 2006 11:04:44 -0000 1.14 --- scheduling.xml 20 Apr 2006 18:51:29 -0000 1.15 *************** *** 1,5 **** <?xml version="1.0" encoding="UTF-8" ?> <chapter id="scheduling"> ! <title>Scheduling jobs using Quartz or Timer</title> <section> <title>Introduction</title> --- 1,8 ---- <?xml version="1.0" encoding="UTF-8" ?> + <!-- <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "../lib/docbook-dtd/docbookx.dtd"> --> + <chapter id="scheduling"> ! <title>Scheduling and Thread Pooling using Spring</title> <section> <title>Introduction</title> *************** *** 13,16 **** --- 16,21 ---- available that allows you to invoke a method of an existing target object (analogous to normal <classname>MethodInvokingFactoryBean</classname> operation). + Spring also features classes for thread pooling that abstract + away differences between Java 1.3, 1.4, 5 and JEE environments. </para> </section> *************** *** 289,291 **** --- 294,507 ---- </section> </section> + <section id="taskexecutor"> + <title> + Using Spring's <classname>TaskExecutor</classname> abstraction + </title> + + <para> + Spring 2.0 introduces a new abstraction for dealing with + Executors. Executors are the Java 5 name for the concept of + thread pools. The odd naming is due to the fact that there + is no guarentee that the underlying implementation of is + actually a pool. In fact in many cases the executor is + single threaded. Spring's abstraction helps bring thread + pooling to Java 1.3 and 1.4 environments as well as hiding + implementations details between 1.3, 1.4, 5, and JEE + environments. + </para> + + <section> + <title> + The <classname>TaskExecutor</classname> Interface + </title> + + <para> + Spring's <classname>TaskExecutor</classname> interface is + identical to the <classname>java.util.concurrent.Executor</classname> + interface. In fact it's primary reason for existence is + to abstract away the need for Java 5 when using thread + pools. The interface has a single method + <classname>execute(Runnable task)</classname> + which accepts a task for execution based on the + semantics and configuration of the thread pool. + </para> + </section> + + <section> + <title> + Where to use a <classname>TaskExecutor</classname> + </title> + + <para> + The <classname>TaskExecutor</classname> was originally + created to give other Spring components an abstraction + for thread pooling where needed. Components such as the + <classname>ApplicationEventMulticaster</classname>, + JMS's <classname>AbstractMessageListenerContainer</classname>, + and Quartz integration use the <classname>TaskExecutor</classname> + abstraction to pool threads. However, if your beans need + thread pooling behavior, it is possible to reuse this + abstraction for your own needs. + </para> + </section> + + <section> + <title> + Types of <classname>TaskExecutor</classname>s + </title> + + <para> + There are a number of pre-built implementations of + <classname>TaskExecutor</classname> included with the + Spring distribution. In all likelihood, you shouldn't ever + need to implement your own. + </para> + + <itemizedlist> + <listitem> + <para> + <classname>SimpleAsyncTaskExecutor</classname> + </para> + + <para> + This implementation does not reuse any threads, + rather it starts up a new thread for each + invocation. However, it does support a + concurrency limit which will block any + invocations that are over the limit until a slot + has been freed up. If you're looking for true + pooling, keep looking further down the page. + </para> + </listitem> + + <listitem id="syncTaskExecutor"> + <para> + <classname>SyncTaskExecutor</classname> + </para> + + <para> + This implementation doesn't even execution + invocations asynchronously. Instead each + invocation takes place in the calling thread. It + is primarily used in situations where + mutlithreading isn't necessary such as simple + test cases. + </para> + </listitem> + + <listitem id="concurrentTaskExecutor"> + <para> + <classname>ConcurrentTaskExecutor</classname> + </para> + + <para> + This implementation is a wrapper for a Java 5 + <classname>java.util.concurrent.Executor</classname>. + There is an alternative, + <classname>ThreadPoolTaskExecutor</classname>, + that exposes the <classname>Executor</classname> + configuration parameters as bean properties. It + is rare to use the <classname>ConcurrentTaskExecutor</classname> + but if the + <link linkend="threadPoolTaskExecutor"><classname>ThreadPoolTaskExecutor</classname></link> + isn't robust enough for your needs, the + <classname>ConcurrentTaskExecutor</classname> + is there. + </para> + </listitem> + + <listitem id="simpleThreadPoolTaskExecutor"> + <para> + <classname>SimpleThreadPoolTaskExecutor</classname> + </para> + + <para> + This implementation is actually a subclass of + Quartz's <classname>SimpleThreadPool</classname> + which listens to Spring's lifecycle callbacks. + This is typically used when you have a + threadpool that may need to be shared by both + Quartz and non-Quartz components. + </para> + </listitem> + + <listitem id="threadPoolTaskExecutor"> + <para> + <classname>ThreadPoolTaskExecutor</classname> + </para> + + <sidebar> + <para> + It is not possible to use any backport or + alternate version of the + <classname>java.util.concurrent</classname> + package with this implementation. Both Doug + Lea's and Dawid Kurzyniec's implementations + use different package structures which will + prevent them from working correctly. + </para> + </sidebar> + + <para> + This implementation can only be used in a Java 5 + environment but is the most typically used + there. It exposes bean properties for + configuring a + <classname>java.util.concurrent.ThreadPoolExecutor</classname> + and wraps it in a <classname>TaskExecutor</classname>. + If you need something advanced such as a + <classname>ScheduledThreadPoolExecutor</classname>, + it is recommended that you use a + <link linkend="concurrentTaskExecutor"><classname>ConcurrentTaskExecutor</classname> </link> + instead. + </para> + </listitem> + + <listitem> + <para> + <classname>TimeTaskExecutor</classname> + </para> + + <para> + This implementation uses a single + <classname>TimerTask</classname> + as it's backing implementation. It's different + from the + <link linkend="syncTaskExecutor"><classname>SyncTaskExecutor</classname></link> + in that the method invocations are executed in a + separate thread, although they are synchronous + in that thread. + </para> + </listitem> + + <listitem> + <para> + <classname>WorkManagerTaskExecutor</classname> + </para> + + <sidebar> + <para> + CommonJ is a set of specifications jointly + developed between BEA and IBM. These + specifications are not JEE standards, but + are standard across BEA's and IBM's + Application Server implementations. + </para> + </sidebar> + + <para> + This implementation uses the CommonJ WorkManager + as its backing implementation and is the central + convience class for setting up a CommonJ + WorkManager reference in a Spring context. + Similarly to the + <link linkend="simpleThreadPoolTaskExecutor"><classname>SimpleThreadPoolTaskExecutor</classname></link>, + this class implements the WorkManager + interface and therefore can be used directly as + a WorkManager as well. + </para> + </listitem> + </itemizedlist> + </section> + </section> </chapter> \ No newline at end of file |
