Действительно ли необходимо создать ASP.NET 4,0 базы данных состояния сеанса SQL, отличные от существующего ASP.NET 2.0 DB 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.сетевых сеансов в 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.

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