Является механизмом состояния сеанса ASP.NET 4.0 SQL обратно совместимым с схемой ASP.NET 2.0 для состояния сеанса или должен/должен мы создать отдельную отдельную базу данных состояния сеанса для нашего ASP Приложения .NET 4.0?
Я все равно склоняюсь к последнему, но база данных 2.0 просто работает, хотя мне интересно, существуют ли существенные различия между схемой/процедурами базы данных ASPState между версиями ASP.NET 2.0 и 4.0. Спасибо.
Не было никакого быстрого ответа на это от кого-либо, поэтому я сделал рытье. Я сгенерировал базу данных 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.)
Подробности для каждой версии изменили хранимую процедуру:
CREATE PROCEDURE dbo.DeleteExpiredSessions
AS
DECLARE @now datetime
SET @now = GETUTCDATE()
DELETE [ASPState].dbo.ASPStateTempSessions
WHERE Expires < @now
RETURN 0
GO
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.
(Хотя существуют некоторые отличия в реализации, не относящиеся к схеме.)