I have a legacy application that is extensively using HttpContext.Cache...
This application is now suppose to move to Windows Azure (multi-role).
It will of course cause problems with cache going out of sync on different roles.
I was thinking about injecting (I'm using Autofac) my "AzureCacheWrapper" (wrapper on Microsoft.ApplicationServer.Caching.DataCache) into HttpContext.Cache so legacy application continues working but uses Azure cache instead?
Normally we should implement something like ICacheProvider but unfortunately there are some 3rd party DLLs that are using cache that we don't have access to (and don't know when 3rd party library is using Http cache)
I don't think cache provider can be configured through web.config (like OutputCaching) so the only solution seems to me to somehow inject my implementation into Add/Insert/Get methods on Runtime Cache.
Unfortunately because of .NET implementation of System.Web.Caching.Cache (sealed class) I don't think I can override HttpContextBase to return different cache or inject into System.Web.Caching.Cache itself...
Thanks for any help! :)
I think your application needs code/architectural change...
If you had your own class which handles getting and setting the cache, Which may easier now to change your code/architecture in one place.
If you are going to use Single role then no problem exist in your scinario. If possible you can run your webrole in ExtraLarge slot.
Related
We have an environment with a vendor deployed application to several front ends on it. It makes heavy use of the ASP .Net storage (Session, Application, and Cache). Problem is with the load this environment quickly brings IIS to it's knees with the amount of data it's trying to keep in memory.
The solution we are trying to go with is to override the storage mechanism and implement our own. (Specifically a Redis server to manage the storage)
We have implemented their cache interface and set up Microsoft.Web.Redis.RedisSessionStateProvider in the web.config to manage the session. That part all works fine. The problem is that the caching inside the vendor application does not always use their provided interface. Decompiling the dll and examining dump files show that there are several instances of them directly calling (for example):
HttpContext.Current.Cache.Insert(...) and HttpContext.Current.Application[...] = ...
Is there any way we can override the HTTPContext* calls so that they'll use Redis to cache instead of the Asp .Net application storage?
When it is a "3rd" party which uses HttpContext.Current you probably have no chance to change that behavior.
Is this other application running within your context (do you control the app domain). Or is it a standalone application?
I once tried to change HttpContext.Current.Cache for unit testing and ended up mocking the whole HttpContext because it was so very internal somewhere in the Microsoft stack.
All this is pretty hard to do, not really recommended and can lead to all kinds of other errors.
In short, don't use HttpContext.Current.Cache. Use something you can inject.
In general, libraries should never use that static context.
It is much more flexible to have abstractions + DI for those kind of things...
For caching, you could use CacheManager for example.
We have a ASMX Web service 2.0 which was created way back and some of our applications still use it. Now we want to add another webmethod to it and I am not sure what effects it may cause with existing clients / apps. Or what precautions I should take while doing that.
I would appreciate your views.
Adding new methods should not cause any problems for the existing clients as long as the interface (signature, web service namespace) of the existing methods remains unchanged. Of course, existing clients cannot call the new methods, but the old ones should work as before.
Though adding methods works, there are explicit ways to version the interface of an ASMX web service. See this link for details.
At the moment I'm implementing some piece of code that makes use of the HttpContext.Current.Application as some kind of caching system. To me it looks like it could easily be replaced by a static Dictionary though, removing the dependency on the HttpContext.
There is this question that is quite similar, but in the answer there is no explanation why anyone would ever go for the HttpApplicationState approach at all.
In summary: what particular problem does the HttpApplicationState solve that is not already solvable in a myriad of other ways?
You should not have a dependency on HttpContext anyway
You can define a interface contract for Cache mechanism
And then implement that by HttpContext, AppFabric and so on
Static will be shared across all http applications hosted within the same application pool, HttpContext.Current.Application would be scoped to the current app. They would only be equivalent if the app pool is hosting only one application.
I'm building a site in Symfony 2.0 that has a fair amount of AJAX, which builds page content with data it gets from an API, like: http://mysite.com/api/pictures/list
Data is handled using Repositories, which are sometimes used in page code so that string of images you see might come from the controller using the PictureRepository, or via Ajax using the API which accesses the PictureRepository.
I'd like to use Memcached to ease the database load, but am not sure where to put the caching code. Is it best to cache the database result, or the API result? Or is the difference negligible? Having the memcached logic inside the Repository would mean writing the code once (regardless of whether it's accessed via the API or directly), but it seems like it would also make sense to avoid accessing the Repository whenever possible.
Thoughts?
My opinion is that memcached should be used for session storage.
For your purposes you should better think about using of Varnish as http cache.
After that, you can configure your application use ESI.
At least, that is how we do it in our applications ;)
Is there a way in .Net to switch out the Cache provider just like I would a membership provider, or role provider? I would like to keep the code untouched but switch to using a distributed cache like memcached or AppFabric.
All I am finding is how to switch out the output cache provider. This might be necessary, but it doesn't solve the issue of when Cache is called directly from within my code.
I've found many libraries and they abstract Cache behind an interface, but this would mean I have to go to every spot in my code and inject the new abstraction. Also I am using PLINQO, which internally uses Cache.
Is OutputCache the only thing I can switch out through configuration?
Thank you in advance.
You may take a look at the following presentation which explains the pre-.NET 4.0 state of caching and what .NET 4.0 brings in this respect. In .NET 4.0 the caching has been completely reworked into a separate assembly (System.Runtime.Caching) and rendered extensible. That's true for both object caching and page output caching. Unfortunately if you have current code that relies on the old Cache class this has to be changed as this class works with in-memory objects only.