Article ID: 326606
Article Last Modified on 3/22/2007
APPLIES TO
- Microsoft ASP.NET 1.1
- Microsoft ASP.NET 1.0
- Microsoft SQL Server 1.1 Standard Edition
This article was previously published under Q326606
SYMPTOMS
When impersonation is enabled for an ASP.NET application that uses SQL Server mode session state management with integrated security, you may see issues that occur when session state is lost or locked for a long time.
CAUSE
ASP.NET may not use impersonation in the following scenarios:
- When you write session state back to SQL Server.
- When you use polling to acquire session state because another user is seen as holding on the same session state data.
WORKAROUND
To work around this problem, use one of the following methods:
- Do not use impersonation.
- If you must use impersonation, do not use integrated security with SQL Server session mode state management.
- If you must use both impersonation and integrated security with SQL Server session mode state management, grant access to the account that is specified in the userName setting of the processModel element. This is located in the Machine.config file on the computer that is running SQL Server.
STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
MORE INFORMATION
SQL Server session state implements its own connection pooling for open SqlConnection objects. When SQL Server session state saves the data back to the SQL Server database, it uses a background thread. The background thread runs under the ASP.NET worker process (Aspnet_wp.exe in the default ASP.NET installation on Microsoft Windows 2000 and on Microsoft Windows XP, and W3wp.exe in the default ASP.NET installation in Microsoft Windows Server 2003) account. The SQL Server connection attempt is successful if an open SqlConnection object can be found in the pool. However, if no open SqlConnection object can be found in the pool, a SqlConnection object is created through the ASP.NET worker process account. If this account does not have permission to connect to the computer that is running SQL Server, the connection is not successful, and this also results in an unsuccessful attempt to write the session data back to the computer that is running SQL Server. By default, a writer lock is used for a session when the session is accessed. Because of this, the session remains locked until a timeout occurs.
REFERENCES
For additional information about using impersonation in ASP.NET applications and using integrated security when you connect to SQL Server, click the following article numbers to view the articles in the Microsoft Knowledge Base:
306158 INFO: Implementing Impersonation in an ASP.NET Application
316989 PRB: "Login Failed" Error Message When You Create a Trusted Data Connection from ASP.NET to SQL Server
For more information about hotfixes and other related updates for ASP.NET and the .NET Framework, visit the following Microsoft Web sites:
.NET Framework - Product Updates
http://msdn2.microsoft.com/en-us/vstudio/aa718353.aspx
ASP.NET Forums
http://forums.asp.net/
Additional query words: trusted_connection sspi
Keywords: kbbug kbhttpruntime kbsecurity kbstate KB326606
