我有一个有关使用EJB计时器服务的方案。
用例，如下：该系统应该能够安排一项任务，该任务将使用某些特定的时间戳进行轮询/询问我们的颠覆存储库以进行文件更改。
这个想法是，每当计划运行的任务时，它都会针对特定的SVN存储库执行命令。出于这个特定目的，我不会调用任何外部过程，而是使用使用svnkit java库的"纯" Java方法http://svnkit.com/
我唯一关心的是：使用EJB计时器服务执行将调用外部流程的任务是一个好主意吗？我的方式将使用"纯" Java方式，但在其他情况下，例如调用批处理文件/命令行/外部可执行文件直接在计时器服务逻辑中。
我担心服务器内存使用/性能等的影响。
这是个好主意吗？
我认为的另一个想法是使用基于客户端的技术（例如SWT/Swing）在服务器中创建一个"桌面"应用管理两个应用程序。我将在Glassfish中创建的"桌面"应用程序和" Web"用户界面。
我倾向于在我选择的应用程序服务器中执行所有操作。
我以前曾使用过EJB计时器，但它仅在不致电任何届时服务的情况下对数据库进行呼吁，而这只是这种情况出现了，所以我在这里提出了一个问题，以收集那些经历过的人的更多想法。
有什么想法？
从理论上讲，EJB不应该依赖外部I/O，因为它会干扰Bean/bean实例，线程等容器/服务器的管理等。
实际上，如果您采取预防措施，这应该有效。例如：
- 将功能隔离到其自己的EJB（即，仅处理这些计时器的无状态会话bean）以避免实例汇总问题
- 在等待命令时使用超时，以免悬挂所有服务器线程
- 确保您不安排计时器，以便您有多个OS命令同时运行
请记住，EJB 3.0计时器是持久的（vs ejb 3.1计时器，可以选择不存在），这意味着：
- 他们可以在集群中的任何服务器上运行。如果您的集群中有多台机器，则需要确保它们都能运行命令。
- 它们在重新启动服务器时生存。如果您安排一个计时器以运行，但服务器在可能的情况下崩溃，则在服务器重新启动时运行。这可能会导致间隔计时器的特定问题（所有错过的计时器都会反复发射），如果您不仔细管理现有时间（您可以轻松创建冗余计时器）。