I have been reading all over the place about the new MemoryCache class starting in .Net Framework 4.0. From what I've read, you can access the MemoryCache across different .Net applications. I am trying to share an object between an Asp.Net application and a standard windows forms .Net application. If I add the object to the MemoryCache in the .Net application, the Asp.Net application does not see it. Is there any way to accomplish this? Thank you for your time, it is greatly appreciated.
Windows Form App:
Dim cache As ObjectCache = MemoryCache.Default
Dim policy As New CacheItemPolicy()
policy.AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(60)
cache.Set("testcache", TestObj, policy)
Asp.Net App:
Dim cache As ObjectCache = MemoryCache.Default
If IsNothing(cache("testcache")) Then Response.Write("TestCache Is Nothing")
Thanks -
Ryan
No, that's not possible. MemoryCache is not a distributed caching solution. So it will only be available locally.
If you are looking for a distributed cache alternative you may want to look into AppFabric or Redis.
However, it does sound a bit like an odd architecture to want to share the cache that way.
Maybe exposing a shared services layer, that both the asp.net and winforms consume, and have just the services implement the caching would seem more logical (take into account I actually know nothing about the problem you are trying to solve, so I could be wrong).
Caching is more commonly used for performance reasons, not as a way to share data among applications.
MySQL memory tables are working great and having stellar performance. 20/30 inserts a second and only around 1% CPU load.
I realize this advice is not timely, but for others reading this question, another possibility is Interprocess Communication (IPC) between the two programs. This way the two programs can exchange messages/data directly without going thru an intermediate.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx
From the documentation above, here are some of your options.
Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets
In your case, mapped memory files might be the best approach as it allows for a shared memory space between applications. Fundamentally, your MySql/Redis approach is probably not that different.
if you are interested in :
single server multiple applications - memory share
you should consider create web api at the same node and consume it (simple key value API)
and use simple Memory Cache provided by .net framework
multiple servers - memory share
free $$ solution
you can use "Distributed SQL Server Cache", allows the
distributed cache to use a SQL Server database as its backing store.
To create a SQL Server cached item table in a SQL Server instance,
you can use the sql-cache tool. The tool creates a table with the
name and schema that you specify.
if you have a cluster of nodes you can use NCache it is
an open source in-memory distributed cache developed natively in
.NET and .NET Core. NCache works both locally and configured as a
distributed cache cluster for an ASP.NET Core app running in Azure
or on other hosting platforms.
solutions that require paying money:
NCache mentioned previously, there's Professional and Enterprise solutions,
or
Redis Cache - Redis is an open-source in-memory data store, which is often used as a distributed cache. You can configure an Azure Redis Cache for an Azure-hosted ASP.NET Core app, and use an Azure Redis Cache for local development.
Related
We are planning to move our web application to web garden environment.
We are leaning towards Windows Server App Fabric Caching to provide distributed caching.
Is it the right approach?/
Is there anyother way to achieve distributed caching apart from Appfabric Caching?
The web garden is many pools on the same computer. So you have only one computer, so any cache application that store the cache on the database on the same computer can do the work.
The key point here is to have a database to keep the cache, because pools can not direact talk to each other and share resources, and the only way to have share data (like cache) is using common database, or common files, or common memory file-map.
The most safer, faster and ready to go is the database.
The Windows Server App Fabric can hold that, can also hold many other computers.
(source: microsoft.com)
Alternative, for web garden and a single computer, if you can handle a database on your project you can easy create your own cache, with a single table, and using mutex for synchronize the data
I have a large data-driven application simple WCF services.
I want to store some of my frequently used data in cache.
I have two options
ASP.NET Cache
Couchbase Cache
I practical perspective which of the cache is efficient, reliable and easy to use with WCF Services and .NET platform?
It depends by your architecture and where you are going to deploy your project.
if by instance you will deploy your project on a server farm Asp.net cache would not be my first choice as it does not support distributes caching (Multiple cache copies not synchronized,Cache lost when worker process recycles,etc) so in this case I would use Couchbase (behind the scene uses a database).
If you will deploy your project on a single web server you may use the Asp.net caching
I'm having a look at the best way of developing a server application that presents an ASP.NET MVC front end for management/reporting.
The server app (service?) will also need to provide TCP listener as well as communicate to devices on a COM port.
The most obvious way I can think of doing this is to have an ASP.NET MVC web app and have a windows service that talks to the web app using a web calls/services. I guess then I'd talk to the service using the tcp listener or remoting?
The only other way would be to actually host an web server component in the service, and not use IIS which seems a bit to over the top.
Does anyone have any experience of this/recommendations?
It's a bit open ended but hope I've explained the basics.
TIA
Sam
I would probably try and decouple things a bit more.
Start off w/ a core project where all your business logic lies (agnostic of how users interact with it); sort of the DDD Domain Model idea.
Then, create two projects which consume that core project, one that is your MVC app, and another that's a WCF or ServiceStack-based service which can handle your TCP stuff.
Share state between them using the normal means; either inter-process comms, shared database, etc.
It sounds to me like you're looking for something very close to Windows Communication Foundation. Your requirements for IIS hosting, ASP.NET communication, and TCP communication. MSDN has a brief overview of WCF up here. There's also an article available about the transportation protocols here.
There are some good -- if a little old -- WCF questions here on Stack Overflow. I've just started delving into this world myself, and I have to admit that it's daunting at first. The Beginner's Guide (found under the first hyperlink above) has some slightly old, but very useful tutorial videos about WCF.
I will say that, although it may seem daunting or difficult, it's certainly better to use an existing, established technology for your purposes than to try to write your own homebrewed solution for something like this.
I started ServiceStack because I needed a high-performance web services framework option that promotes the correct way to develop web services.
ServiceStack can be run on top of any ASP.NET host or self-hosted using the HttpListener option. See the Starter Templates for example projects of a Console App or Windows Service hosts. Although even under IIS, ServiceStack is very fast and imposes very little overhead with a hello world service executing in sub <1ms response times.
ServiceStack also comes with .NET's fastest text serializers and a myriad of high-performance caching providers so you can escape the XML config bound ASP.NET's session and caching provider model.
Because ServiceStack encourages a clean message-based development model your same web services can take advantage of the Redis MQ Host allowing it to be invoked outside of HTTP context using Redis as a broker - with no code-changes required.
Redis is one of the fastest distributed NoSQL data stores.
I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application in azure.
What challenges could we possibly encounter when we try to port an existing asp.net application to azure? Are there any other alternatives to azure in cloud computing?
For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.
However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):
You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).
So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.
It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.
If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.
Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.
The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.
Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/
Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.
Also this question here What is the difference between an Azure Web Site and an Azure Web Role
I have an ASP.NET application that makes extensive use of ASP.NET cache API for caching commonly-used data. In addition, I am using polling-based sql cache dependency to track expiration.
The drawback of the current design is that, in the web farm environment, each web server has its own data cache that is not shared across servers.
Is there a way I can simply migrate the code to share data cache across multiple servers?
I've thought of using memcached however that would not work with sql cache dependency, right?
Any other solutions?
Have you looked at Windows Server AppFabric (Formerly Velocity).
http://blogs.msdn.com/velocity/
You could use following options -
Use the approach described here for synchronizing the data across web farms -
http://www.eggheadcafe.com/articles/20030420.asp
Use distributed caching approach
Use enterprise library cache.
It seems to me that Windows Server AppFabric is exactly what you are looking for. (AKA "Velocity"). From the introductory documentation:
Windows Server AppFabric provides a
distributed in-memory application
cache platform for developing
scalable, available, and
high-performance applications.
AppFabric fuses memory across multiple
computers to give a single unified
cache view to applications.
Applications can store any
serializable CLR object without
worrying about where the object gets
stored. Scalability can be achieved by
simply adding more computers on
demand. The cache also allows for
copies of data to be stored across the
cluster, thus protecting data against
failures. It runs as a service
accessed over the network. In
addition, Windows Server AppFabric
provides seamless integration with
ASP.NET that enables ASP.NET session
objects to be stored in the
distributed cache without having to
write to databases. This increases
both the performance and scalability
of ASP.NET applications.