DB2读取提交而不锁定？

我们有一个正在修改记录的事务。事务必须调用一个web服务，如果服务失败，则回滚事务，以便它不能提前提交。由于记录已修改，客户端应用程序对其进行了锁定。但是，web服务必须检索该记录，以便在处理过程中从中获取信息。砰，死锁

我们使用websphere，出于让我难以理解的原因，它默认为可重复读取隔离级别。我们将其拆下以读取_committed，认为这样可以在不查找锁的情况下检索行。在我们的开发环境中，这似乎是可行的，但在登台阶段，我们遇到了死锁

我不是问它为什么表现不同，我们可能在某个地方犯了错误。我也没有询问上面的web服务示例的细节，因为很明显，同样的事情也可能发生在其他地方

但从读取文档的角度来看，read_committed似乎在读取过程中获得了一个共享锁，因此将等待另一个事务（在本例中为客户端应用程序）持有的独占锁。但我不想进入read_uncommitted隔离级别，因为我不想进行脏读。有没有不那么极端的解决方案？我需要一些中间地带，在那里我可以在没有任何锁等待的情况下执行读取，并且只检索提交的数据

---

有没有这样的解决方案？不太脏，不太脏？如果不是在siolation级别，也许我可以在SQL上添加一些修饰符？有什么吗？

读取已提交行的最低隔离级别是读取已提交

通常，在DB2数据库中处理行的方式如下：

无读取锁定的读取数据库行普通选择已提交读取。 处理数据，使您有一个值已更改的行。 使用读取锁定再次读取数据库行。选择以进行更新 选中以查看1中的数据库行。匹配3中的数据库行。 如果行匹配，则更新数据库行。 如果行不匹配，请释放更新锁并返回到2。

---

我假设您谈论的是jdbc隔离级别，而不是db2。db2中的read_committed游标稳定性和repeatable_read-read稳定性的区别在于共享锁保持的时间。repeatable_read保留满足谓词的每个锁，而read_committed则只保留锁，直到找到与谓词匹配的另一行

你比较过计划了吗？如果计划不同，你可能会有不同的行为

有没有升级

假设您使用的是9.7+，您是否尝试过当前提交

---

Pre-current\u committed，其中包含以下设置：DB2\u SKIPINSERTED、DB2\u EVALUNCOMMITTED和DB2\u SKIPDELETED

，但我认为OP希望在处理过程中防止对行进行任何更改。这将允许报告，但不会阻止改变。@GilbertLeBlanc我想你对这个问题有点误解。问题在于，read committed的读取操作确实锁定了记录，尽管是短暂的、非独占的。但是，由于它希望获得锁，如果另一个事务锁定了行，则读取将等待，而不是完成。这通常不是什么大问题，但在我第一段中描述的场景中，这会产生死锁b/c服务和客户端位于不同的连接上，即使它们在一起工作。锁的目的是防止其他东西更改行，对吗？不是为了以后可以更新吗？或者是否允许其他进程更新该行，您的进程只需在之后处理该行？你能在本地调用Web服务吗？我知道db2支持在同一个会话中共享锁，但如果您先从盒子中路由出去，这种情况可能不会发生。其他Web服务的锁定级别是多少？@Clockwork Muse-不，客户端确实在锁定以准备更新。webservice实现了一个自定义的工作流通知方案，该方案必须查询相关记录以生成通知，尽管它读取的字段与正在更新的字段不同，但这并不会真正改变任何内容。web服务和客户端当前以read committed运行。我担心我们的DB lead支持的最简单的修复方法是将服务改为“未提交”，但我正在尝试找到一个替代的b/c，我讨厌这个答案。您是否介意其他人同时更新该行？这些值是否可以在以后使用差异来更新它们，而不管发生了什么其他操作？或者根本不在乎是否有人同时更新了记录，并覆盖了更改？你确定你不能在服务的同一个盒子上运行它，可能使它成为同一个会话的一部分吗？@Clockwork Muse同一个盒子，尽管作为一个web服务，这并不总是正确的。不同的连接池。我希望web服务不要寻找共享锁，并返回提交的锁

---

当它查询时使用ata。我目前的理解是，前者只能发生在readuncommitted中，这会导致脏读。web服务是纯只读的。但是因为readcommitted寻找共享锁，所以它会等待独占锁被释放……这不会发生，因为客户机拥有独占锁并且正在等待web服务。我不想要未提交的数据，这就是我不喜欢UR的原因。不，这个死锁不是基于升级的，尽管我们过去有过这种死锁。我从来没有听说过你现在犯了罪。我会去读的，我读过了，这正是我们想要的。Cur_commit是一个不死锁、不肮脏阅读的金发区。不幸的是，我们现在使用的是v9.5，但是我们已经在进行一项转换工作来推出v10.5，所以我们只需要等一会儿。谢谢