If I update session state, should I lock it, too? Are concurrent accesses by multiple requests executing on multiple threads a concern with session state?
Ans) Concurrent accesses aren’t an issue with session state, for two reasons. One, it’s unlikely that two requests from the same user will overlap. Two, if they do overlap, ASP.NET locks down session state during request processing so that two threads can’t touch it at once. Session state is locked down when the HttpApplication instance that’s processing the request fires an AcquireRequestState event and unlocked when it fires a ReleaseRequestState event. 30) ASP.NET’s application cache supports expiration policies and cache removal callbacks. Expiration policies are based on time dependencies and file dependencies. Are database dependencies supported, too? In other words, can I have an item automatically removed from the cache in response to a database update? Ans) In ASP.NET version 1.x, no. However, you can forge a link between databases and the ASP.NET application cache by combining file dependencies with database triggers. For details, and for working sample code, see Jeff Prosise
Related Questions
- If I update session state, should I lock it, too? Are concurrent accesses by multiple requests executing on multiple threads a concern with session state?
- How is May Intersession via Special Session different from YRO State Support Summer Term?
- How does Oracle9iAS Portal maintain session context across HTTP requests?
