批量下.docVIP

4.3、配置一个“任务启动器” 最简单的“任务启动器（JobLauncher）”接口的实现是“SimpleJobLauncher”。它只依赖于一个“任务存储器（JobRepository）”，使得拥有任务执行的能力： 只要拥有了“任务执行器（JobExecution）”，它将调用“任务”的执行方法，最终将“任务执行器”返回给调用者： 当从一个调度器开始启动时，执行顺序是径直的，并且运作良好。但如果从一个网站请求开始启动，那么问题就来了。在这个场景中，运行的过程需要是异步的，才能使得“SimpleJobLauncher”立即返回一个结果给调用者。这是因为长时间挂起一个网站请求而去运行一个批量任务肯定是行不通的。如下图时序图所示： 通过配置一个“子任务执行器（TaskExecutor）”这样简单的操作，就能使得“SimpleJobLauncher”适用于这个场景： 任何一个“子任务执行器”接口的实现、都能被用作去控制任务的异步执行。 4.4、运行一个任务 在运行一个任务时，有两样东西是必不可少的：需要运行的“任务（Job）”和一个“任务启动器（JobLauncher）”。他俩既可以放在同一个上下文中，也可以放在不同的上下文里。比如，当从命令启动一个任务时，一个新的Java虚拟机（JVM）将被实例化用来服务每个任务，如此一来，每个任务便有了它自己的“任务启动器（JobLaucher）”。但如果通过Web容器，通过“页面请求（HttpRequest）”，通常只会存在一个“任务启动器（JobLauncher）”，并且被配置为异步启动模式，这样多个请求才能并行不悖。 4.4.1、从命令行启动任务 对于想要从一个企业级别调度器运行任务的用户来说，命令行是首选的。这是因为大多数调度器（Quartz是个例外，使用了NativeJob）直接以操作系统进程的形式运行，普遍的通过系统脚本开始启动。除此之外还有很多方式启动一个java进程，比如Perl，Ruby，甚至诸如ant或maven这样的“构建工具（build tools）”。但因为大多数人习惯于脚本，这个例子将主要关注这个。 、命令行任务启动器（CommandLineJobRunner） 因为脚本启动一个任务必须通过java虚拟机，所以需要一个包含有“main”方法的类用来作为程序的入口。Spring Batch提供了一个实现恰能满足这个要求：“命令行任务启动器（CommandLineJobRunner）”。必须注意到这只是启动任务的一种方法，除此之外有大量其它的方式启动一个java进程，千万不要以为这是必由之路。“命令行任务启动器（CommandLineJobLauncher）”运行为四大步骤： 加载适当的应用上下文 解释命令行参数为“任务参数（JobParameter） 基于参数定位适当的任务 使用“任务启动器（JobLauncher）”提供启动任务时需要的应用上下文 所有这些步骤将只根据传入的参数执行直至完成。如下是必须的参数列表： 这些参数必须依照“路径（path）”为先、“名称（name）”随后的顺序传入。所有之后的参数都被认为是“任务参数”，而且格式必须为“名称=值”： 大多数时候你需要显示申明你打包在jar文件中的main方法所在的类，但为了简单起见，直接使用即可。例子中使用了同一个域下相同的“EndOfDay”。第一个参数是“endOfDayJob.xml”，指明了包含任务的spring“应用上下文（ApplicationContext）”。第二个参数“endOfDay”表明了任务名称。最后的参数，“schedule.date(date)=2007/05/05”将被转换为“任务参数（JobParameters）”。XML的配置例子如下： 这个例子过于简单了，因为通常在spring batch中启动一个任务有多得多的需要的地方，但用它来表示两个“命令行启动器（CommandLineJobRunner）”基本的两项配置还是不错的：“任务（Job）”以及“任务启动器（JobLauncher）”。 、退出码 一般在通过命令行启动一个批量任务时，总是使用一个企业级的调度器。大多数的调度器是在后台执行、并且仅在进程级别。这意味着它们仅仅知道操作系统进程相关的信息，比如它们调用的shell脚本。在这种场景下，告知后台调度器某个任务是成功还是失败，只能通过任务执行后的返回码。所谓返回码就是指被执行的进程在最后返回给调度器的结果代码。最简单的情况下：0表示成功，1表示失败。不过通常的场景比这个要复杂得多：如果任务A返回4就开始任务B，如果返回5就开始任务C。这样类型的行为就可以再调度器级别进行配置，但重要的是当前使用的框架，比如spring batch，要提供这样一个途径、为某个特殊的任务返回