Thread-safe caching in ASP.NET HttpModules

Here's the scenario

I have an ASP.NET 4.0 application which has a LOT of legacy URL rewrites. I want to build an HTTP module that will look at a database of these rewrites and do a 301 redirect if needed. There's tens of thousands of reco开发者_JS百科rds in this table.

So obviously I need to do some sort of caching so I'm not hitting the database and searching through all those records for each page request.

One of our requirements is to have a fast start up time when our application recycles for some reason (worker process recycles or what have you). So I don't want to load the whole table at app start up. The app start up is already excruciatingly slow.

My brilliant/ridiculous idea is to,

1. At app start up in my HttpModule create an empty dictionary to hold rewrites.
2. Start a background worker thread. The app continues starting up.
3. The background worker thread updates the dictionary with say, oh, the most 1000 most used rewrites.

Questions

My questions are:

1. Is this ridiculous?
2. Is there such a thing as a thread-safe dictionary? The background thread might be updating the dictionary while new requests are coming in.
3. Would all the locking that goes on in a thread-safe collection slow down incoming requests?

Thanks!!

If you're targeting .NET 4.0, you can use ConcurrentDictionary and it will take care of all the magic for you in terms of concurrency. Just use the GetOrAdd for incoming requests and AddOrUpdate for your background population idea.

I would also like to pose something for you to think about as well. If you've got these thousands of URLs are you really only running on one server? I ask that because you're only talking about a local caching scheme here. If you have three servers all of them are going to be pounding the DB for the URL data. Are you looking into a distributed caching technology like Windows Server AppFabric or Memcached?