如何阻止Firebird 2.5存储过程同时多次执行

嘿，我懂你现在的急事儿——Firebird 2.5的存储过程被网站并发调用搞出问题，要快速加个“互斥锁”，暂时没法折腾队列那种最优方案对吧？刚好Firebird有几种类似SQL Server锁定机制的临时解决办法，给你说两个实操性强的：

这是最常用的临时锁方案，原理是用一张单条记录的表，通过行级锁来确保同一时间只有一个存储过程实例能执行。

步骤1：创建锁表并初始化记录 #

先建个专门存锁的表，然后插入对应你目标存储过程的锁记录：

-- 创建锁表
CREATE TABLE PROCEDURE_LOCKS (
    PROCEDURE_NAME VARCHAR(100) NOT NULL PRIMARY KEY,
    LAST_LOCKED TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 插入你要保护的存储过程的锁记录
INSERT INTO PROCEDURE_LOCKS (PROCEDURE_NAME) VALUES ('YOUR_TARGET_PROC_NAME');

步骤2：修改存储过程，添加锁逻辑 #

在存储过程的最开头，加上获取行锁的语句。这个语句会自动阻塞后续并发调用，直到当前存储过程执行完成（事务提交/回滚后锁自动释放）：

CREATE OR ALTER PROCEDURE YOUR_TARGET_PROC_NAME(/* 你的参数 */)
RETURNS(/* 返回值 */)
AS
BEGIN
    -- 第一步：获取互斥锁，并发调用会在这里等待
    SELECT 1 FROM PROCEDURE_LOCKS 
    WHERE PROCEDURE_NAME = 'YOUR_TARGET_PROC_NAME'
    FOR UPDATE;

    -- 下面是你原来的INSERT/UPDATE逻辑
    -- ... 你的业务代码 ...

    -- 事务提交后锁会自动释放，不需要手动解锁
END

如果不想让后续调用等待，而是直接返回“正在执行”的提示，可以改成非阻塞模式，用FOR UPDATE NOWAIT并捕获锁冲突异常：

CREATE OR ALTER PROCEDURE YOUR_TARGET_PROC_NAME(/* 你的参数 */)
RETURNS(/* 返回值 */)
AS
BEGIN
    -- 尝试非阻塞获取锁
    SELECT 1 FROM PROCEDURE_LOCKS 
    WHERE PROCEDURE_NAME = 'YOUR_TARGET_PROC_NAME'
    FOR UPDATE NOWAIT;
EXCEPTION
    WHEN LOCK_CONFLICT THEN
        -- 抛出自定义异常，或者返回特定标识给调用方
        EXCEPTION '存储过程正在执行，请稍后再试';
END

Firebird自带一个GET_LOCK UDF（用户定义函数），可以实现类似SQL Server的应用级锁。不过这个方案依赖UDF是否已在你的数据库中启用，步骤如下：

步骤1：确认UDF已加载 #

先检查rdb$functions表，看是否存在GET_LOCK：

SELECT * FROM rdb$functions WHERE rdb$function_name = 'GET_LOCK';

如果没有，可能需要手动加载（Windows下通常是fbintl.dll中的函数，Linux是libfbintl.so）。

步骤2：在存储过程中使用锁 #

在存储过程开头调用GET_LOCK获取锁，执行完成后调用RELEASE_LOCK释放：

CREATE OR ALTER PROCEDURE YOUR_TARGET_PROC_NAME(/* 你的参数 */)
RETURNS(/* 返回值 */)
AS
DECLARE VARIABLE LOCK_HANDLE INTEGER;
BEGIN
    -- 获取锁，第一个参数是锁名称，第二个是等待超时（毫秒，0表示不等待）
    LOCK_HANDLE = GET_LOCK('MY_PROC_LOCK', 0);
    IF (LOCK_HANDLE = 0) THEN
    BEGIN
        EXCEPTION '存储过程正在执行，请稍后重试';
    END;

    -- 你的业务逻辑
    -- ...

    -- 释放锁
    RELEASE_LOCK(LOCK_HANDLE);
END

• 不管用哪种方案，事务的提交/回滚是锁释放的关键，确保你的存储过程执行完后事务能正常提交（如果是调用方管控事务，要确保调用逻辑正确）。
• 这个方案是临时救急的，正如你所说，队列处理才是长期的最优解——比如把网站请求放进队列，用单线程消费执行存储过程，从根源避免并发问题。

内容的提问来源于stack exchange，提问作者Steve Graham