HostFileChangeMonitor is not invalidatinmg the cache immediately after updating the file
-
Tuesday, August 28, 2012 1:10 PM
Class Program
{
static void Testcaching()
{
ObjectCache cache = MemoryCache.Default;
string fileContents = cache["filecontents"] as string;
if (fileContents == null)
{
CacheItemPolicy policy = new CacheItemPolicy();List<string> filePaths = new List<string>();
string cachedFilePath = @"C:\sns\sns.txt";
filePaths.Add(cachedFilePath);
policy.ChangeMonitors.Add(new
HostFileChangeMonitor(filePaths));// Fetch the file contents.
fileContents = File.ReadAllText(cachedFilePath);cache.Set("filecontents", fileContents, policy);
}
}
static void Main()
{
try
{
Testcaching();
ObjectCache cache = MemoryCache.Default;
File.WriteAllText(@"C:\sns\sns.txt","sns");
// Thread.Sleep(100);
if (cache["filecontents"] != null)
Console.WriteLine( "Failed" );
else
{
Console.WriteLine( "Passed" );
}
}
I am using system.Runtime.Caching.Cahe in .Net 4.0.
i am using HostFileChangeMonitor for cache invaliding.
after updating the file its not invaledating the cache immediately. at least its taking 100 ms time for invalding the cache. Which is not acceptable in my application.- Moved by Bob ShenMicrosoft Contingent Staff Wednesday, August 29, 2012 7:46 AM (From:Visual C# General)
All Replies
-
Wednesday, August 29, 2012 9:55 AMModerator
Hi Som,
Welcome to the MSDN Forum.
>>at least its taking 100 ms time for invalding the cache.
During my test, it is not true. Sometimes, I set the period to 1, and it works fine. During my test, the period is not the same, sometimes is 5 and sometimes is 50, not very certainly.
On my opinion, this is related to how the changes are captured.
http://msdn.microsoft.com/en-us/library/system.runtime.caching.hostfilechangemonitor.aspx
When the HostFileChangeMonitor class is used in a non-ASP.NET application, the FileSystemWatcher class is used internally to monitor files.
The FilesystemWatcher reports the changes when it captured a related windows message. So you can image:
When you changed the file, OS noticed it and sent a message to all listeners, then, FileSystemWatcher captured this message, and then HostFileChangeMonitor get it. There are a series of operations. It takes time.
I think this is the reason, and there is no appropriate solution. Use Thread.sleep(100) can be a workaround.
Best regards,
Mike Feng
MSDN Community Support | Feedback to us
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
-
Monday, September 03, 2012 7:28 AM
Hi Mike,
Thanks a lot for ur reply.
ya u are right, time varies, i haven take 100 ms for surity.
Meanwhile i have found that EnterpriseLibray. Chaching block is working as expected. I dont know how. As i have seen the caching block code it is also uisng the FileSystemWatcher class.
In this sceniario with which one i should go...
- Marked As Answer by Mike FengMicrosoft Contingent Staff, Moderator Friday, September 07, 2012 6:32 AM
-
Tuesday, September 04, 2012 1:37 AMModerator
Hi Som,
If so, my suggestion is "EnterpriseLibray. Chaching block". Because it is certain. In your original way, you have used sleep(100) for surety. But the time period is unexpected, there is a possibility that it could over 100ms, in this scenario, you might not get expected result, and it is hard to reproduce, that makes your system unsteady.
Best regards,
Mike Feng
MSDN Community Support | Feedback to us
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

