Every 3 tier Windows app has to deal with this . Answer - the state is never guaranteed for any instant.
The reason being is one client updates the data and until the DB verifies it it can not be used i the cache ( the DB may crash midway , or there may be a data error on constraint / concurrency exception) . You can change the cache after the DB has updated but in the mean time one client has the new data. Also there is the possibility that another client accesses the data , it is not in the cache , after it is written to the DB and before the cache is updated so there clients will have the new data. Basically you gurantee a time that data will be propogated through the system 1 second , 5 second etc . 2 common ways of doing it Method1 use a changes table. After the Data has been send to the DB Update the cache. Other machines poll the changes table every so often in the DB . Method 2 Get 1 cache to tell the other caches via queues or remoting. Method 1 is more stable becaue even if the first machine has a problem the other machines will still update the data from the DB to flush dirty elements out of the cache. Method 2 s more efficient in terms of DB resources but requires the system to have knowledge of all other caches. Ben -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Stefan Avramtchev Sent: Thursday, 27 June 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Synchronsing events caches across web farms... Alex, >It's an ASP.Net based website - so currently I'm think that perhaps we could >use remoting to force the caches on all machines to repopulate when a change >occurs on one web server... I'd add a couple of questions more on that topic: "And what if some of the machines failed to 'repopulate' (or let me say 'reconfigure' here)? Ingnore? Retry? Abort?" "What guaranties that your entire Web farm is in consistent (predictable) state after the 'repopulation' was ordered or even finished?" I think the problem is real interesting if it's to be solved once and forever. stef You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
