JPA 更新查询——为什么我的交易不起作用？

Question

我在 JavaDB (Derby) 写入事务时遇到性能问题。每笔交易需要超过 500 毫秒，而我一天可能有数十万笔交易。我期望在 MySql 上部署，我不知道是否会遇到同样的问题，但在尝试之前我正在尝试提高 Derby 的性能。

一个事务涉及更新一串记录——多达 6 条记录，如下所示：

public void update(List<Tally> list) {
    try {
        utx.begin();
        for (Tally tally : list) em.merge(tally);
        utx.commit();
    // etc

我想看看 UPDATE 查询是否会工作得更好，因为 JPA 不必跟踪更新的列并组成 SQL 查询（侧面）问题：这是一个好的理论吗？）

所以我编写了一个如下所示的命名查询：

@NamedQuery(name="TallyUpdate",
   query="UPDATE Tally t SET t.vote = t.vote + 1 WHERE t.id IN :idSet"

操作如下：

@PersistenceContext protected EntityManager   em;
@Resource           protected UserTransaction utx;    
public void incrementVote(List<Long> idList) {
    Query q = em.createNamedQuery("TallyUpdate");
    q.setParameter("idSet", idList);
    try {
        utx.begin();
        q.executeUpdate();
        utx.commit();
    //etc

executeUpdate() 调用总是抛出异常：

SEVERE: javax.persistence.TransactionRequiredException: executeUpdate is not supported for a Query object obtained through non-transactional access of a container-managed transactional EntityManager
    at com.sun.enterprise.container.common.impl.QueryWrapper.executeUpdate(QueryWrapper.java:225)

JPA 实现是 EclipseLink 2.3。 0

那是什么word-salad 异常的含义以及我应该如何运行更新？

结果发布：

I did move the createnamedQuery() call to after the utx.begin() call and the update started working. I am not sure why but I am going to run with it for now.

还没有关于相对表现的结果，但我上面的帖子具有误导性。计票时，会采用 24-36 种不同的方式进行计票，而不是 6 种。因此，对原始 update() 方法（使用 merge()）进行了六次调用）每个都有大约 6 条记录的列表。正是这个调用集合花费了超过 500 毫秒。如果 Tally 表为空，则该基准仅约为 27 毫秒，这大约是我希望看到的速度。当表填充到 50,000 行或更多时，我会看到 500ms+ 的数字。

如果有人对我发布的结果感兴趣，请评论说出来。

PS这是一个在GlassFish 下运行的JSF 应用程序，而不是EJB。我不确定这是否与性能有关。

Answer 1

由于您有一个容器管理的实体管理器，我猜您已将其注入到 EJB 中。因为这种情况意味着事务由容器管理，即您不需要在代码中显式启动它们。默认情况下，事务在 EJB 方法启动时开始，在该方法完成时结束。这是针对无状态 EJB 的。对于有状态 EJB，事务可以跨越多个方法调用，并在调用 EJB“销毁”方法时结束。所以你应该决定：你要么使用容器管理的实体管理器（一个注入到 EJB 中，就像你在这里一样），然后让容器管理事务（通过 JTA），或者创建一个应用程序管理的实体管理器，然后处理自己在代码中进行交易。

关于性能，Apache 人员表示 Derby 非常适合生产，在某些情况下可以匹配甚至有时甚至超越 MySQL 和 PostgreSQL，正如您可以在 Apache 文档中看到的那样：

http://home.online.no/~olmsan/publications/pres/apachecon05us/apachecon05.pdf

持保留态度，Derby 并不因其性能而闻名于世。甚至这个文档也表明，在某些情况下，Derby 比 MySQL 慢很多。而且 Derby 的 CPU 使用率更高。

我的建议：再次在 MySQL 中进行概念验证，并在该数据库上进行基准测试。如果这就是您要在生产中使用的内容，那么在不同的数据库上对应用程序进行性能调整没有多大意义。