ASP.Net static objects - asp.net

I'm trying to cache some information that I've retrieved from a database. I've decided to use a static List<> member to store the information. I know from my experience with List<> in multithreaded applications that I need to protect access to it with the lock statement. Do I treat any code in my Asp.Net code the exact same way? Will the lock statement still work?

A lock statement around List method's would definitely work but if you need caching functionality in your ASP.NET application I would recommend you using Cache class which is adapted to this functionality.

Lock will work. Be aware that if there are multiple worker processes, you will end up with multiple versions of the list. Each of them will be protected by its own lock.
A pretty real danger here is that if you fail to release the lock, your entire web application might hang. A user might get disconnected while your ASP.NET page is executing; so be careful of exceptions thrown at unexpected times.

It depends upon whether you're going to modify the List. Here's a good discussion of this subject: Do i need a lock on a list? C#

Related

When to load database drive configuration settings in ASP.NET?

At application start our application connects to the database and fetches a language translation table and caches it into memory. The code that does this is placed in Application_Start in Global.ascx
The problem with this approach is that if the database is not available, there will be a completely unhandled exception. Because the code is set at Application_Start, Request and Response are not available.
I was wondering if there's a general lightweight approach to this.
My plan is to implement a singleton to store the state of the connection attempt, and then check that on the default routed page. It's a solution, but I feel there's something missing. Are there any other approaches to this?
The problem with this approach is that if the database is not
available, there will be a completely unhandled exception.
Well handle it then. You could implement some retry policy in your code so that if the result is not cached in memory it will fetch it from the database once again.
The excellent article about the error handling can be find at http://blog.gauffin.org/2011/11/how-to-handle-errors-in-asp-net-mvc/#.UZsZ6LVTAus
. And jgauffin also had a discussion's thread at What is best practice for global error/exception handling in ASP.NET MVC?
Hope this help.

Saving audit data to database asynchronously in asp.net webforms application

I have an asp.net 3.5 web application which generates alot of audit related data. Since that data isn't immediately relevant to the user, I'd like to be able to save it to the MSSQL database asynchronously and let the user go onto the next page without waiting. I'm using Nhibernate as my ORM.
I've looked into PageAsyncTasks and as far as I can tell they simply allow you to perform page operations in parallel, but all operations still have to complete before the page finishes loading. Is there an alternative, fairly lightweight method to have asynchronous processing that will continue on without affecting page load? Is simply spinning up a new thread manually an acceptable process?
You could create a web service within your solution and when your server-side code is finished and ready to move the user on to the next page it could call your web service to do the auditing as a fire and forget type thing.
Not sure if the NHibernate session is threadsafe so if you create a new thread be careful with the context.
Ideally you could use queues and a servicebus to deal with this sort of thing safely and async but that involves architectural changes.
Not sure if this is possible but if the auditing is actually noticeably slowing the UI down maybe you'd be better off to improve that process and keep it synchronous. Either way, good luck.

NHibernate, Sqlite, missing tables and IOC fun

I'm doing unit testing on a class library that uses NHibernate for persistence. NHibernate is using a Sqlite in-memory database for testing purposes. Under normal circumstances, it's easy to get StructureMap to kick out a session for me.
However, because I'm using the in-memory database to improve testing speed, I need to have a single session available for the duration of a test (because it blows the database away when I create a new one). And there is another wrinkle. The case that is currently burning me is testing a custom NHibernate-based ASP.NET membership provider. These are created apparently once per AppDomain, so I shouldn't inject the session into it, for obvious reasons.
Is there a way in structuremap to tell it to get rid of an instance of a particular type while still maintaining the bits that tell it how to instantiate that type? Really, if I could get away with it, I would just make it act like the HttpScoped object lifetime, but apparently I can only do that within the context of an Http request. Is there a straightforward way to manually control the lifetime of an object coming out of structuremap?
I apologize for the length of this and the possibility that it is a dumb question. I'm solo on this project, so I don't really have anyone to bounce ideas off of.
You could wrap the session in your own ISession implementation which delegates to a real session which lifetime you control. Then register your own ISession as instance.
I ended up making two constructors for my provider along with a private variable of type Func. By default, its value was set to my standard code for creating a session using StructureMap's ObjectFactory.
The overloaded constructor accepted as a parameter an object of type Func. That way, I can inject a strategy for creating an instance of that type if needed, but otherwise don't have to go through any extended effort. In the case of my test, I created the session in the NUnit setup method and destroyed it in the Teardown. I don't love this idea, but I don't currently hate it enough to rip it out....yet.
This got rid of the error I was experiencing in regard to the tables. However, it appears that NHibernate for some reason cannot write to an in-memory sqlite database under the conditions I created. I'm now working on testing to see if I can write to one in the file system. It isn't ideal, but it will be a good long while (I hope), before the performance of writing to disk really starts hurting.

Implement second level cache in ASP.Net

Is there any way to use caching in ASP.Net except SQL Server second level cache. As it is the first time to work with caching I want any way with an example. I have found that NHibernate implements this but we are using .netTiers as an application framework.
The Session cache seems to be the appropriate caching mechanism here. The Session cache is a fault-tolerant cache of objects.
Inserting an object
Session["Username"] = "Matt";
Reading an object
string username = (string)Session["Username"];
Removing an object
Session.Remove("Username");
I say fault-tolerant because if the value with the key you specify doesn't exist in the Session cache, it will not through an exception, it will return null. You need to consider that when implementing your code.
One thing to note, if you are using Sql Server or State Server, the objects you can put in the cache need to be serializable.
Memcached is also a very good way to go, as it is very flexible. It is a windows service that runs on any number of machines and your app can talk to the instances to store and retrieve from the cache. Good Article Here

Is the HttpContext.Current.Cache available to all sessions

As per title. I want to be able to save some data in a cache object but this object must be available to all users/sessions and can expire.
What is the best method to achieve this in a asp.net web app?
HttpContext.Current is available to all pages, but not necessarily to all threads. If you try to use it inside a background thread, ThreadPool delegate, async call (using an ASP.NET Async page), etc., you'll end up with a NullReferenceException.
If you need to get access to the cache from library classes, i.e. classes that don't have knowledge of the current request, you should use HttpRuntime.Cache instead. This is more reliable because it doesn't depend on an HttpContext.
HttpContext.Current.Cache will be present, but Current should only be used if you cant get to your context member.
Also to answer your second question, yes, the Cache object is global to the application.
Here's a good intro to caching...
How to cache in ASP.NET by using Visual C# .NET
and...
Caching with ASP.NET . Don't skip part 2, "Data Caching"

Resources