据我了解，LockAcquisitionException 会在线程尝试更新被另一个线程锁定的记录行时发生。 （如果我错了，请纠正我）
所以我尝试如下模拟：
我使用dbVisualizer 锁定了一行记录，然后我使用应用程序对同一记录运行更新查询。最后，我只是打了global transaction time out，而不是LockAcquisitionException，原因码为68。
因此，我认为我的理解是错误的。 LockAcquisitionException 不会以这种方式发生。可以建议或举一些简单的例子来创建LockAcquisitionException 吗？
【问题讨论】：
标签： java hibernate db2 timeout db2-luw
由于锁定超时，您将收到 LockAcquisitionException (SQLCODE=-911 SQLERRMC=68)。
比较 dbViz 和 hibernate 的操作可能没有帮助，因为它们可能在 jdbc 级别使用不同的类/方法和设置，这会影响异常详细信息。重要的是，在 Db2 级别，无论他们报告锁定超时的异常名称如何，两者都经历了 SQLCODE=-911 和 SQLERRMC=68。
您可以在 UPDATE 或 DELETE 或 INSERT 或 SELECT（以及其他包括 DDL 和命令）等语句上获得锁定超时，具体取决于许多因素。
所有的锁定超时都有一个共同点：一个事务等待太久而被回滚，因为另一个事务没有足够快地提交。
Lock-timeout 诊断和 Lock-Timeout 避免是不同的主题。
等待锁的时间长度可以根据选择的设计在数据库级别、连接级别或语句级别设置，包括混合这些。您还可以通过调整 CUR_COMMIT、LOCK_TIMEOUT 等数据库参数以及在语句级别或连接级别调整隔离级别来调整 Db2 锁定的行为方式。
在考虑避免之前确保准确诊断是明智的。
在运行 Db2-LUW v10.5.0.9 时，请考虑仔细研究此页面和所有相关链接：
有许多情况会导致锁定超时，因此最好准确了解哪种情况与您的情况相关。
避免锁冲突是配置和事务设计的问题，所以这是一个更大的话题。配置可以在 Db2 级别或应用程序层或两者兼而有之。
有时错误会导致锁定超时，例如，当应用程序服务器线程的数据库连接挂起且尚未提交且应用程序未正确清理时。
您应该诊断锁定超时的参与者。有多种方法可以对 Db2-LUW 进行锁定冲突诊断，因此请选择适合您的方法。
在 V10.5.0.9 上仍然有效的一个简单诊断工具是使用 Db2 注册表变量 DB2_CAPTURE_LOCKTIMEOUT=ON, 尽管该方法已被弃用。您可以即时设置此变量（并取消设置），而无需任何服务中断。因此，如果您有一个导致 SQLCODE=-911 SQLERRMC=68（锁定超时）的可重新创建场景，您可以打开此变量，重复测试，然后关闭该变量。如果变量已打开，并且发生了锁定超时，那么 Db2 将编写一个新的文本文件，其中包含有关锁定情况中参与者的信息，其中显示有助于您了解正在发生的事情的详细信息，并让您考虑解决问题的方法。有足够的事实。您不希望永久设置此变量，因为如果您获得大量锁定超时，它会影响性能并填满 Db2 诊断文件系统。所以你必须小心。在此页面的知识中心中阅读有关此变量的信息： https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005657.html 您可以通过仔细研究这些文件的内容来诊断锁定超时，当然也有必要了解详细信息。这是一项常规的 DBA 活动。
另一种方法是使用带有定制 db2cos 脚本的 db2pdcfg -catch 来决定在 Db2 抛出 -911 之后要做什么。这需要脚本技能，它可以让您准确决定在 -911 之后收集哪些诊断信息以及将这些诊断信息存储在哪里。
另一种涉及更多工作但可能带来更多红利的方法是使用event monitor for locking。文档位于：
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0054074.html
请务必同时学习“相关概念”和“相关任务”页面。
【讨论】：