На это никто не ответил быстро, поэтому я немного покопался. Я создал базу данных ASPState
с помощью инструмента aspnet_regsql.exe
из .NET 2.0, а затем сделал то же самое, используя тот же инструмент, но из .NET 4.0. Затем я создал сценарии для каждой из этих баз данных SQL Server и использовал инструмент сравнения для выявления различий.
Я обнаружил следующее: Единственное существенное отличие схемы ASPState
от версий .NET 2.0 до .NET 4.0 - это хранимая процедура dbo.DeleteExpiredSessions
. Это хранимая процедура, периодически вызываемая SQL Запланированное задание агента сервера также установлено инструментом.
Следовательно, может показаться, что схема для ASPState 2.0 и ASPState 4.0 полностью совместима , и поэтому нет необходимости с технической точки зрения разделять состояние сеансов ASP.NET 2.0 и ASP.NET 4.0 & Ndash; но я все равно, вероятно, сделаю это.
(Этот вывод несколько удивил, поскольку 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 2.0.
Еще одна вещь, которую я узнал из поста в блоге, который я не знал: механизм состояния сеанса ASP.NET 4.0 теперь предлагает сжатие . Поиск по compressionEnabled
в элемент sessionState (схема настроек ASP.NET) .
Наконец, я также нашел кое-что важное от Microsoft, на Краткий обзор выполнения ASP.NET . Выдержки:
...
Если SQL Server используется для управления
состояние сеанса, все версии ASP.NET
(.NET Framework), которые
установлен на тот же компьютер может
поделиться сервером состояний SQL, который
установлен с последней версией
ASP.NET. Схема для состояния сеанса
одинаков во всех версиях
ASP.NET.
(Хотя существуют некоторые различия в реализации, не относящиеся к схеме.)