是 ASP.NET 4.0 SQL会话状态的机制与ASP.NET 2.0架构的会话状态向后兼容，还是应该/必须，我们为我们的ASP一个独立和独特的会话状态数据库.NET 4.0的应用程序？

Is the ASP.NET 4.0 SQL session state mechanism backward-compatible with the ASP.NET 2.0 schema for session state, or should/must we create a separate and distinct session state database for our ASP.NET 4.0 apps?

我倾向于后者，无论如何，但2.0数据库的似乎的只是工作，虽然我不知道是否有2.0之间的ASPState的数据库架构/程序之间的实质性区别4.0版本的ASP.NET。谢谢你。

I'm leaning towards the latter anyway, but the 2.0 database seems to just work, though I'm wondering if there are any substantive differences between the ASPState database schema / procedures between the 2.0 and 4.0 versions of ASP.NET. Thank you.

推荐答案

有一个从人对这个没有快速的答案，所以我做了一些挖掘。我生成使用 aspnet_regsql.exe的工具从.NET 2.0 ASPState的数据库，然后我也用了同样的事情同样的工具，但是从.NET 4.0。然后，我从每次得到的SQL Server数据库中生成的脚本，并使用了比较工具来隔离不同。

There was no quick answer on this from anybody, so I did some digging. I generated an ASPState database using the aspnet_regsql.exe tool from .NET 2.0, and then I did the same thing using the same tool but from .NET 4.0. Then, I generated scripts from each of those resulting SQL Server databases and used a comparison tool to isolate the differences.

我的发现是：从.NET 2.0到.NET 4.0版本的 ASPState的模式之间唯一的重大差异是 DBO .DeleteExpiredSessions 存储过程。这是该存储过程由SQL Server代理计划的作业也安装该工具定期调用。

What I found is: The only material difference between the ASPState schema from .NET 2.0 to .NET 4.0 versions is the dbo.DeleteExpiredSessions stored procedure. That's the stored procedure called periodically by a SQL Server Agent scheduled job also installed by the tool.

因此​​，它似乎是的架构ASPState的2.0和4.0 ASPState的是完全兼容的，所以它是没有必要，从技术角度看，来隔离ASP.NET 2.0和ASP.NET 4.0会话国家＆ndash的;但我很可能会最好这样做。

Consequently, it would seem that the schema for ASPState 2.0 and ASPState 4.0 are perfectly compatible and so it's not necessary, from a technical standpoint, to segregate ASP.NET 2.0 and ASP.NET 4.0 session state – but I'll likely do it anyway.

（这个结果有点出人意料，因为ASPState的改变了很多，从.NET 1.1到.NET 2.0。）

(This finding was a bit surprising, as ASPState changed a lot from .NET 1.1 to .NET 2.0.)

对于每个版本的改变存储的过程详细说明：

Details for each version's changed stored proc:

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博客文章：

As for why the above change was necessary, I found the following MSDN blog post:

节选，在参考了旧的程序：

Excerpt, in reference to the older procedure:

...   这将采取所有的锁   过期的记录删除，   这些锁可能会升级到页   锁。这可以引起死锁   与其他会话状态写   语句'时的记录数   标记为删除增加。通过   默认此存储过程   应该以每分钟运行一次。   ......

... This would take the locks on all the expired records for deletion and these locks may be promoted to page locks. This can give rise to deadlocks with other ‘session state write statements’ when the number of records marked for deletion increases. By default this stored procedure is supposed to run every minute. ...

因此​​，该存储过程的新版本可能是可取的ASP.NET 2.0应用程序了。

Consequently, the newer version of the stored proc may be advisable for ASP.NET 2.0 apps, too.

还有一件事我从博客文章了解到，我不知道：ASP.NET 4.0中的会话状态的机制，现在提供的 COM pression 。搜索关于 COM pressionEnabled 在 sessionState元素（ ASP.NET设置架构）。

One more thing I learned from the blog post that I did not know: ASP.NET 4.0 session state mechanism now offers compression. Search on compressionEnabled at sessionState Element (ASP.NET Settings Schema).

最后，我也只是发现了有关微软的东西，在 ASP.NET侧并行执行概述。摘录：

Finally, I also just found something relevant from Microsoft, at ASP.NET Side-by-Side Execution Overview. Excerpt:

...   如果SQL Server用于管理   会话状态下，所有版本的ASP.NET   这是（的.NET框架）   安装在同一台计算机上可   共享SQL状态服务器是   与最新版本的安装   ASP.NET。 的会话状态模式   在所有版本的相同   ASP.NET。

... If SQL Server is used to manage session state, all versions of ASP.NET (of the .NET Framework) that are installed on the same computer can share the SQL state server that is installed with the latest version of ASP.NET. The schema for session state is the same in all versions of ASP.NET.

（尽管有执行不特定的模式有所不同。）

(Though there are some differences in implementation not specific to the schema.)