我做了一个应用程序来对网络节点进行一些测试,例如 ping 测试、检索磁盘空间等。
我使用预定的批处理来运行操作,但我想知道这是否是批处理的正确使用?
EJB 计时器是否应该更相关?此外,当我运行一个批处理时,我的 glassfish 服务器会保留批处理作业的日志,我不需要它(尤其是一天生成的批处理作业量)。
如果我需要在相同的计划时间内运行一些工作,我认为批处理可以做到,但 EJB 计时器也可以吗?
您能否就实现这一目标的正确方式给我您的意见?
谢谢,厄施
我做了一个应用程序来对网络节点进行一些测试,例如 ping 测试、检索磁盘空间等。
我使用预定的批处理来运行操作,但我想知道这是否是批处理的正确使用?
EJB 计时器是否应该更相关?此外,当我运行一个批处理时,我的 glassfish 服务器会保留批处理作业的日志,我不需要它(尤其是一天生成的批处理作业量)。
如果我需要在相同的计划时间内运行一些工作,我认为批处理可以做到,但 EJB 计时器也可以吗?
您能否就实现这一目标的正确方式给我您的意见?
谢谢,厄施
当您的任务在眨眼间(或附近)执行时,使用 EJB 计时器是合适的。
否则使用批处理机制。
从 EJB 计时器执行的长时间运行的任务可能会出现问题,因为它们在事务中执行,而这些事务通常会在短时间内超时。增加这个事务超时也会增加数据库和可能影响应用程序正常运行的其他资源锁的机会。
这不是一个有明确答案的问题,但是将您的应用程序作为批处理作业会产生一些成本,我会看看我得到了什么,看看是否值得这样做。
因此,您正在考虑一项由单个 Batchlet 步骤组成的工作。好吧,无论是在作业中的失败步骤还是在块步骤中利用检查点,“重新启动”功能都不会获得任何收益。batchlet 编程模型非常简单……即使您真的喜欢@BatchProperty,您现在也必须处理 XML 才能这样做。
如果您想与其他批处理作业一起开始、查看和管理这些执行,这只会变得更有趣。这可能是因为您正在使用提供某种特定于实现的附加功能的实现。这方面的一个例子可能是与外部调度程序软件的集成,允许由它调度作业。在另一个极端,如果您发现在一个地方(作业存储库,通常是持久性数据库)保存所有批处理作业执行的记录很有价值,那么这对您来说也是值得的。
但是,如果您不关心这些,则可以选择 EJB 计时器。