Нужно ли создавать базу данных состояния сеанса SQL ASP.NET 4.0, отличную от существующей базы данных ASP.NET 2.0 ASPState?

Ни от кого не было быстрого ответа, поэтому я покопался. Я создал базу данных ASPState с помощью инструмента aspnet_regsql.exe из .NET 2.0, а затем проделал то же самое, используя тот же инструмент, но из .NET 4.0. Затем я сгенерировал сценарии из каждой из полученных баз данных SQL Server и использовал инструмент сравнения, чтобы выделить различия.

Я обнаружил следующее: Единственное существенное отличие схемы ASPState от версий .NET 2.0 до .NET 4.0 - это dbo.DeleteExpiredSessions хранимая процедура. Это хранимая процедура, периодически вызываемая запланированным заданием агента SQL Server. инструментом.

Следовательно, может показаться, что схемы для ASPState 2.0 и ASPState 4.0 полностью совместимы, и поэтому с технической точки зрения нет необходимости разделять состояние сеанса ASP.NET 2.0 и ASP.NET 4.0 - но Скорее всего, я все равно это сделаю.

(Этот вывод был немного неожиданным, поскольку ASPState сильно изменился с .NET 1.1 на .NET 2.0.)

Подробная информация об изменении сохраненной процедуры каждой версии:

.NET 2.0 ASPState DeleteExpiredSessions хранимая процедура:

CREATE PROCEDURE dbo.DeleteExpiredSessions
AS
    DECLARE @now datetime
    SET @now = GETUTCDATE()

    DELETE [ASPState].dbo.ASPStateTempSessions
    WHERE Expires < @now

    RETURN 0   
GO

.NET 4.0 ASPState DeleteExpiredSessions хранимая процедура:

CREATE PROCEDURE dbo.DeleteExpiredSessions
AS
    SET NOCOUNT ON
    SET DEADLOCK_PRIORITY LOW 
    DECLARE @now datetime
    SET @now = GETUTCDATE() 
    CREATE TABLE #tblExpiredSessions 
    ( 
        SessionID nvarchar(88) NOT NULL PRIMARY KEY
    )
    INSERT #tblExpiredSessions (SessionID)
        SELECT SessionID
        FROM [ASPState].dbo.ASPStateTempSessions WITH (READUNCOMMITTED)
        WHERE Expires < @now
    IF @@ROWCOUNT <> 0 
    BEGIN 
        DECLARE ExpiredSessionCursor CURSOR LOCAL FORWARD_ONLY READ_ONLY
        FOR SELECT SessionID FROM #tblExpiredSessions 
        DECLARE @SessionID nvarchar(88)
        OPEN ExpiredSessionCursor
        FETCH NEXT FROM ExpiredSessionCursor INTO @SessionID
        WHILE @@FETCH_STATUS = 0 
            BEGIN
                DELETE FROM [ASPState].dbo.ASPStateTempSessions WHERE
                    SessionID = @SessionID AND Expires < @now
                FETCH NEXT FROM ExpiredSessionCursor INTO @SessionID
            END
        CLOSE ExpiredSessionCursor
        DEALLOCATE ExpiredSessionCursor
    END 
    DROP TABLE #tblExpiredSessions
RETURN 0     
GO

Что касается того, почему это изменение было необходимо, я нашел следующее сообщение в блоге MSDN:

• Тупик при сохранении сессий Asp.net на SQL-сервере во время пиковой нагрузки

Отрывок, относящийся к более старой процедуре:

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

Следовательно, более новая версия хранимой процедуры может быть рекомендована и для приложений ASP.NET 2.0.

Еще одна вещь, которую я узнал из сообщения в блоге, я не знал: механизм состояния сеанса ASP.NET 4.0 теперь предлагает сжатие. Выполните поиск на compressionEnabled по адресу sessionState Элемент (схема настроек ASP.NET).

Наконец, я также нашел кое-что актуальное от Microsoft по адресу Обзор параллельного выполнения ASP.NET. Отрывок:

...
Если для управления состоянием сеанса используется SQL Server, все версии ASP.NET (.NET Framework), установленные на одном компьютере, могут совместно использовать сервер состояния SQL, установленный с последней версией ASP.NET. Схема состояния сеанса одинакова во всех версиях ASP.NET.

(Хотя есть некоторые различия в реализации, не относящиеся к схеме.)