Question

有几天我在使用Glassfish的Java应用程序上遇到了死锁问题 - 带有Mysql InnoDB的EJB3

配置： Mysql InnoDB：Ver 14.12 Distrib 5.0.51a，debian-linux-gnu（i486）使用readline 5.2

应用程序服务器：Glassfish v2.1

持久化EJB3 - JPA - Hibernate

为了简单起见，我有 - 一个带有servlet的SOA系统，用于处理用户对服务，登录，注销，支付和注册等的订阅...... - 石英工作系统（cron触发器），处理这些服务的每日减少，“低信用”警告的产生，支付的验证等......

我的问题：我在加载测试期间到处都遇到了死锁（10万用户模拟 - 30次请求/秒）

返回了堆栈示例：

Message ID: 
Could not synchronize database state with session org.hibernate.exception.LockAcquisitionException

Complete Message:   
Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:105) at 
org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at
org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275) at 
org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:114) at 
org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:109) at 
org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:244) at 
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2382) at 
org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335) at 
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635) at 
org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115) at 
org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at 
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at 
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) at 
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at 
org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:64) at
org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996) at 
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1141) at 
org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) at 
org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:67) at
net.xxx.server.dao.impl.PaymentDAOImpl.listPaymentsByStateAndCompany(PaymentDAOImpl.java:270)

注意结束，这是我完成的代码： net.xxx.server.dao.impl.PaymentDAOImpl.listPaymentsByStateAndCompany（PaymentDAOImpl.java:270）

此功能：

private static final String QUERY_FOR_PAYMENTS_BY_STATE_AND_COMPANY = " FROM " + Payment.class.getName()
        + " p WHERE p.serviceDefinition.company=:company"
        + " AND p.state = :state";

    @SuppressWarnings("unchecked")
    public List<Payment> listPaymentsByStateAndCompany(Company company,Constants.PaymentState state) {
        List<Payment> payments = this.getEntityManager()
        .createQuery(QUERY_FOR_PAYMENTS_BY_STATE_AND_COMPANY)
        .setParameter("state",state.ordinal())
        .setParameter("company",company)
        .getResultList();
        return payments;
    }

此功能在未进行负载测试时效果非常好，例如我们每5秒就有1个请求。

在负载测试期间，我们有高频运行的作业（例如，每5秒）。

我不会只得到这个错误，但其他一些工作也是如此（仍然是死锁）！

关于MYSQL：

死锁示例：

------------------------
LATEST DETECTED DEADLOCK
------------------------
090428 12:21:11
*** (1) TRANSACTION:
TRANSACTION 0 14286818, ACTIVE 0 sec, process no 21872, OS thread id 802850 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 1024, undo log entries 2
MySQL thread id 298, query id 11843357 localhost 127.0.0.1 root Updating
/*  */ update service set balance=40.0, company_id=2, last_on='2009-04-28 12:19:55', modified_by='server', modified_on='2009-04-28 12:21:11', service_definition_id=3, state=1, subscriber_id=13578, valid_until='2010-02-22 12:13:52' where service_id=693
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 62 n bits 176 index `PRIMARY` of table `xxx/service` trx id 0 14286818 lock_mode X locks rec but not gap waiting
Record lock, heap no 98 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 8; hex 80000000000002b5; asc         ;; 1: len 6; hex 000000d9faa0; asc       ;; 2: len 7; hex 0000000cc91e70; asc       p;; 3: len 4; hex 00001c42; asc    B;; 4: len 8; hex 80001245aad4e363; asc    E   c;; 5: len 6; hex 736572766572; asc server;; 6: len 8; hex 80001245aad4e3c9; asc    E    ;; 7: len 1; hex 81; asc  ;; 8: len 8; hex 80001247f200df08; asc    G    ;; 9: len 8; hex 8000000000000002; asc         ;; 10: len 8; hex 8000000000000003; asc         ;; 11: len 8; hex 800000000000350a; asc       5 ;;

*** (2) TRANSACTION:
TRANSACTION 0 14286798, ACTIVE 1 sec, process no 24963, OS thread id 393239 starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
17 lock struct(s), heap size 1024, undo log entries 16
MySQL thread id 253, query id 11843359 localhost 127.0.0.1 root Updating
/*  */ update payment set credit=1.0, currency='EUR', modified_by='9999900092', modified_on='2009-04-28 12:21:11', payment_definition_id=7, price=1.0, service_definition_id=3, state=0, subscriber_id=13578, transaction_id=11463 where payment_id=15914
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 62 n bits 176 index `PRIMARY` of table `xxx/service` trx id 0 14286798 lock mode S locks rec but not gap
Record lock, heap no 47 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 8; hex 8000000000000286; asc         ;; 1: len 6; hex 000000d9ffce; asc       ;; 2: len 7; hex 0000000cc90683; asc        ;; 3: len 4; hex 0000f841; asc    A;; 4: len 8; hex 80001245aad4e3b2; asc    E    ;; 5: len 6; hex 736572766572; asc server;; 6: len 8; hex 80001245aad4e3ff; asc    E    ;; 7: len 1; hex 81; asc  ;; 8: len 8; hex 80001245d450fed8; asc    E P  ;; 9: len 8; hex 8000000000000002; asc         ;; 10: len 8; hex 8000000000000003; asc         ;; 11: len 8; hex 80000000000034db; asc       4 ;;

交易隔离

我在互联网上阅读有关交易隔离的内容。

在glassfish上我们可以设置事务隔离级别，我把它读为未提交。

它不起作用，然后我在mysql中设置了相同的级别：

mysql> SELECT @@global.tx_isolation;
+-----------------------+
| @@global.tx_isolation |
+-----------------------+
| READ-UNCOMMITTED      | 
+-----------------------+
1 row in set (0.00 sec)

mysql> SELECT @@tx_isolation;
+------------------+
| @@tx_isolation   |
+------------------+
| READ-UNCOMMITTED | 
+------------------+
1 row in set (0.00 sec)

SVP有人可以告诉我可能是什么问题吗？我真的不知道!!!!

BTW我在互联网上看到你可以为每个请求选择你的事务隔离级别...... 是否可以直接为JPA上的方法设置事务隔离级别？因为我认为只有那些进行全局数据更新的工作（比如减少15000个服务）应该是不读的，我错了吗？

Answer 1

我对您的问题没有确切的答案，但这可能会帮助您缩小范围。

死锁可能发生在任何事务隔离级别，因为即使在“未提交读取”的情况下，innodb也会对更新设置锁定。

您可以使用以下简单方案对此进行测试：

CREATE TABLE locktest (a INT(11), b INT(11), PRIMARY KEY (a)) ENGINE=INNODB;
INSERT INTO locktest VALUE (1, 1);
INSERT INTO locktest VALUE (2, 1);

然后，打开2个mysql控制台（C1和C2）并按顺序运行这些命令：

C1> BEGIN;
C2> BEGIN;
C1> UPDATE locktest SET b = b + 1 WHERE a = 1;
C2> UPDATE locktest SET b = b + 1 WHERE a = 2;
C1> UPDATE locktest SET b = b + 1 WHERE a = 2;
C2> UPDATE locktest SET b = b + 1 WHERE a = 1;

您将在C2上看到死锁，并且即使在未提交读取时C1也会成功完成。如果您检查引擎日志，您将看到类似的报告。

如果删除表上的主键，命令甚至会更早地阻塞，这是因为如果有一个索引覆盖设置锁的查询，innodb锁定会更好。

所以，回到你的问题。

您应该检查以死锁结束的事务中涉及的所有查询，并确保存在相应的索引。如果MySQL必须进行全表扫描，它将结束锁定超过它需要的次数。

这些tips帮助我解决了我的应用中的一些死锁问题。防止死锁的一种好方法是使用“SELECT ... FOR UPDATE”设置写锁以锁定某些父行。

因此，例如，如果您有多个交易尝试更新某些特定客户数据，您可以发出“SELECT id FROM customer WHERE id = 123 FOR UPDATE”，他们将在该点按顺序等待而不是结束持有锁定彼此需要。

Answer 2

我在使用Oracle数据库的Java应用程序中遇到了类似的问题。

我发现数据库缺少外键索引，这导致数据库锁定的行数超过了所需数量，导致高度并发测试死锁。

这是一篇非常好的诊断文章。本文的大部分内容都是特定于oracle的，但有些内容也适用于其他关系数据库： http://www.oratechinfo.co.uk/deadlocks.html

Answer 3

您应该理所当然地认为，无论您做什么，任何事务数据库都会发生死锁。你应该优雅地处理它们并重复失败的事务一定次数（3通常是可以的） - Glassfish中的某个地方应该有一个参数负责。

InnoDB死锁与read-uncommited！ - Java - Glassfish - EJB3（JPA / Hibernate）

3 个答案: