0

如果我从应用程序中的多个线程调用以下代码，是否存在死锁风险？用于为此连接到数据库的事务在此调用之前打开，并在它返回后关闭。应用程序：Java 数据库：Oracle

  FUNCTION reserveWork(in_batch_id NUMBER,
                       in_work_size NUMBER,
                       in_contentType_id NUMBER) RETURN NUMBER IS
    rows_reserved NUMBER := 0;

  BEGIN
    UPDATE
          D_Q1
    SET
          DQ1_BAT_ID = in_batch_id
    WHERE
         DQ1_BAT_ID is null
         AND DCT_ID = in_contentType_id
         AND ROWNUM < (in_work_size + 1);

    rows_reserved := SQL%ROWCOUNT;

    RETURN (rows_reserved);

  END;
4

3 回答 3

2

为了发生死锁，您必须具备这两个条件。

  1. 每个事务必须有多个锁。

  2. 必须以不同的顺序抓住锁。

条件 1 为真，因为您的每个线程都锁定了多行。条件 2 在理论上是正确的，因为返回的行的顺序是不确定的。例如，线程 1 可能会尝试更新第 1、2、3 行，而线程 2 可能会尝试更新第 3、2、1 行。

实际上，Oracle 可能总是以相同的顺序返回行，因此它可能永远不会死锁。无论如何，准备好处理 ORA-00060 错误并重新提交请求。

另一个想法是分两步完成。第一个过程执行 SELECT * WHERE ... FOR UPDATE NO WAIT 来锁定行，如果不返回 ORA-00054，则第二个过程执行实际更新。否则你重试。

无论哪种方式，请确保您将 CREATE TABLE 中的 INITTRANS 设置为将同时更新表的客户端数量。

于 2009-02-04T22:24:58.727 回答
1

如果您在同一张表上运行多个 UPDATE，则存在一定的死锁风险。

特别是因为我在您的代码中看不到 COMMIT 或 ROLLBACK？我认为这是在 JDBC 中完成的？

UPDATE 花费的时间越长，死锁风险就越高。

于 2009-02-04T17:54:46.900 回答
1

当事务 A 锁定一条记录然后必须等待事务 B 解锁记录，而事务 B 正在等待已被事务 A 锁定的记录时，就会发生死锁。

Oracle 有一个非常复杂的机制来处理更新过程中对表的更改。看

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:11504247549852

通常，事务运行的时间越长，事务更改的数据越多，死锁的风险就会增加。我想说这不太可能死锁，但可能会“排队” - 如果您有三个或四个并发会话运行此 SQL，每个会话将具有相同的 SQL 执行路径，将识别相同的更新行，一个会先找到他们，其他人会等待。当第一个事务完成时，另一个事务将重新获取记录，发现它们已更改，然后按照 Tom Kyte 的文章中所述重新启动并选择下一组行。

如果您使用的是 11g，则可以使用 SKIP LOCKED。它存在于早期版本中，但未记录在案。因此，您将自行承担使用风险。

http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_10002.htm#SQLRF01702

这样一来，你

SELECT primary_key BULK COLLECT INTO pk_variable_array FROM D_Q1
WHERE    DQ1_BAT_ID is null
AND DCT_ID = in_contentType_id
AND ROWNUM < (in_work_size + 1)
FOR UPDATE SKIP LOCKED;
--
FORALL i in 1..pk_variable_array
 UPDATE D_Q1
 SET DQ1_BAT_ID = in_batch_id
 WHERE primary_key = pk_variable_array(i)
于 2009-02-04T22:30:52.537 回答