Является ли эта хранимая процедура потокобезопасной? (или любой другой эквивалент на SQL Server)

Вероятно, вы не хотите использовать IDENT_CURRENT - это возвращает последний идентификатор, сгенерированный для рассматриваемой таблицы, в любом сеансе и любой области. Если кто-то другой вставит вставку не в то время, вы вместо этого получите его идентификатор!

Если вы хотите получить идентификатор, сгенерированный только что выполненной вставкой, лучше всего использовать OUTPUT для его получения. Раньше для этого обычно использовалась SCOPE_IDENTITY (), но есть проблемы с этим при параллельных планах выполнения.

Основной эквивалент безопасности потоков в SQL - это выполнение нескольких операторов, вызывающих неожиданное или нежелательное поведение. Два основных типа такого поведения, о которых я могу думать, - это блокировка (в частности, взаимоблокировки) и проблемы параллелизма.

Проблемы с блокировкой возникают, когда оператор останавливает доступ других операторов к строкам, с которыми он работает. Это может повлиять на производительность, и в худшем случае два оператора вносят изменения, которые невозможно согласовать, и возникает взаимоблокировка, в результате чего один оператор завершается.

Однако простая вставка, подобная той, что у вас, не должна вызывать блокировки, если только не задействовано что-то еще (например, транзакции базы данных).

Проблемы параллелизма (описывающие их очень плохо) вызваны тем, что один набор изменений в записях базы данных перезаписывает другие изменения в тех же записях. Опять же, это не должно быть проблемой при вставке записи.

Самый безопасный способ пойти сюда, вероятно, - использовать предложение Output, поскольку при определенных обстоятельствах (многопараллельная обработка) есть известная ошибка в scope_idendity.

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
AS
BEGIN
  DECLARE @NewID INT

  BEGIN TRANSACTION
  BEGIN TRY
    declare @ttIdTable TABLE (ID INT)
    INSERT INTO 
      [dbo].[TicketNumber]([CreatedDateTime], [CreatedBy])
    output inserted.id into @ttIdTable(ID)
    VALUES
      (GETDATE(), SUSER_SNAME())

    SET @NewID = (SELECT id FROM @ttIdTable)

    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION
    SET @NewID = -1
  END CATCH

  RETURN @NewID
END

Таким образом, вы должны быть потокобезопасными, поскольку предложение output использует данные, которые вставка фактически вставляет, и у вас не будет проблем с областями или сеансами.

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
    @NewID int OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION
        INSERT INTO 
            [dbo].[TicketNumber] ([CreatedDateTime], [CreatedBy])
        VALUES
            (GETDATE(), SUSER_SNAME())

        SET @NewID = SCOPE_IDENTITY()

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF XACT_STATE() <> 0
            ROLLBACK TRANSACTION;
        SET @NewID = NULL;
    END CATCH
END

Я бы не использовал RETURN для значимого использования данных: ни набора записей, ни выходного параметра. RETURN обычно используется для состояний ошибки (как в большинстве случаев хранящиеся в системе процессы):

EXEC @rtn = EXEC dbo.uspFoo
IF @rtn <> 0
    --do error stuff

Вы также можете использовать предложение OUTPUT, чтобы вместо этого вернуть набор записей.

Это «потокобезопасный», то есть его можно запускать одновременно.

Во-первых, почему бы вам все время просто не возвращать новый номер билета вместо 0? Какая-то конкретная причина для этого?

Во-вторых, чтобы быть абсолютно уверенным, вы должны заключить свои инструкции INSERT и SELECT в TRANSACTION, чтобы ничто извне не могло вмешаться.

В-третьих, с SQL Server 2005 и новее я бы заключил свои операторы в блок TRY .... CATCH и откатил транзакцию, если она не удалась.

Затем я бы попытался по возможности избегать указания сервера базы данных (TestDB42) в моих процедурах - что, если вы хотите развернуть этот процесс на новом сервере (TestDB43) ??

И, наконец, я бы никогда не использовал SET NOCOUNT в хранимой процедуре - это может привести к тому, что вызывающий абонент ошибочно решит, что сохраненная процедура завершилась неудачно (см. Мой комментарий к gbn ниже - это потенциальная проблема, если вы используете ADO.NET SqlDataAdapter только объекты; см. документы MSDN о том, как изменить ADO.NET data с помощью SqlDataAdapter для получения дополнительных объяснений).

Итак, мое предложение для вашей хранимой процедуры было бы следующим:

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
AS
BEGIN
  DECLARE @NewID INT

  BEGIN TRANSACTION
  BEGIN TRY
    INSERT INTO 
      [dbo].[TicketNumber]([CreatedDateTime], [CreatedBy])
    VALUES
      (GETDATE(), SUSER_SNAME())

    SET @NewID = SCOPE_IDENTITY()

    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION
    SET @NewID = -1
  END CATCH

  RETURN @NewID
END

Марк

Я согласен с ответом Дэвида Холла, я просто хочу немного рассказать о том, почему identity_current - это абсолютно неправильная вещь для использования в этой ситуации.

У нас здесь был разработчик, который его использовал. Вставка из клиентского приложения произошла в то же время, когда база данных импортировала миллионы записей посредством автоматического импорта. Возвращенный ему идентификатор был из одной из записей, импортированных моим процессом. Он использовал этот идентификатор для создания записей для некоторых дочерних таблиц, которые теперь были прикреплены не к той записи. Хуже того, сейчас мы не знаем, сколько раз это происходило, прежде чем кто-то не мог найти информацию, которая должна была быть в дочерних таблицах (его изменение производилось в течение нескольких месяцев). Мало того, что мой автоматический импорт мог повлиять на его код, но другой пользователь, вставивший запись во время smae, мог сделать то же самое. Ident_current никогда не следует использовать для возврата идентификатора только что вставленной записи, поскольку он не ограничен процессом, который ее вызывает.