Java 应用服务器作业还是数据库作业？

在我基于java的应用程序中，我需要一个从一组表中读取数据并将其插入另一个表的作业。在我的第一个设计中，我创建了一个oracle作业，并安排它频繁地执行该过程。 不幸的是，当作业失败时，没有足够的关于失败根本原因的信息。此外为许多系统实例部署系统使工作更加困难。

---

作为替代工作，我尝试将作业作为Weblogic作业移动到我的应用程序服务器中。这是否是一个好的设计？

将我的工作转移到application server之后，我面临以下优势：

跟踪作业失败更容易

非DBA用户可以轻松读取应用程序服务器日志并修复问题。（许多用户无法访问生产线中的数据库。）

作业的逻辑已经从我的数据访问层移到了我的业务逻辑层，由于设计模式的缘故，它更容易被接受

---

“看情况而定”。您的现有方法已经遇到了一些问题。这并不是说你不会在不同的方法中遇到问题。例如，在通过应用程序服务器读/写数据时，您是否消耗了可以在其他地方更好地使用的CPU周期（例如面向客户的进程）。@radimpe：您是对的。你有什么建议？我两个都用过。作为一名“非数据库开发人员”，我倾向于将事情转移到应用程序中，但重点绝对必须放在关注点的分离上。例如，如果您运行一个网站，您不应该让“归档订单”的计划作业干扰用户尝试购买某物的正常操作。根据您可用的资源，这可能很棘手。我可以说，我还发现数据库作业令人沮丧地难以调试——这也是我喜欢应用程序选项的另一个原因，尽管数据库作业有它的位置。我还建议使用应用程序层。正如radimpe所提到的，调试应用程序比调试数据库更容易。使用应用程序时，您可以使用线程（假设您有多个CPU）并行处理它，使其更快。>>不幸的是，当作业失败时，没有足够的关于失败根本原因的信息可用。这一投诉与这是一项数据库工作这一事实并不真正相关。您需要编写数据库代码（PL/SQL？）来记录作业周期的所有方面—开始、结束、处理的行和错误。我还认为，在Weblogic中创造一份工作本来就没有什么比这更容易的了。创建数据库作业只是可以放入单个文件中的一系列SQL命令。您能轻松创建Weblogic作业吗？