Yes I see your point with 3 tier Win forms and I admit in most solutions what I have done is fixed each client to one MidTier server ( though they can failover and the intial connection can be load balanced) - otherwise you have a very complex situation. This sort of goes against stateless midTier servers but I prefer to make this sacrifice.
Another solution is after the DB has been updated - update each cache and ensure readers of those items are locked until the entire transaction update has finished. at least that way you see all the transaction or none of the transaction in the cache. Is this what you meant by OLTP synchronizing the cache ? This lock could be a big performance hit though. Ben. -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Stefan Avramtchev Sent: Friday, 28 June 2002 5:06 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Synchronsing events caches across web farms... Ben, I agree this is tipical problem to solve in 3-tier architectures and in this particular case the Web farm will be happy with the proposed solutions. But, in order for things to work this way, one client request/transaction/message should be processed by BCs using the same version (update, instance or whatever) of the cache. Thus requiring the architecture to promise at least this as a guarantee. How to do that? Well, it's intuitive to keep the boudary of the transaction not spawn across machines (or apps, depends on what the cache is) or use disributed OL transactions (the performance of the latest everybody knows about). OLTP synchronizing the cache update would do the job. And probably this is what most of the solutions employ. But what if we have to reconfigure the BCs in some way? Then we want to know if all machines comitted the changes and if not ... well, then you exclude the failed machine from the site, but this changes your topography and you have to reconfigure again but differently... blaghhh.. You see the dead circle don't you and here OLTP is no good. So if we have high requirements for performance, availability and if we need to use more than one PC on the way of the transaction then we still have a problem to think about. No golden rule here I think, but consider the concrete solution's architecture and requirements. stef BTW, I know about Group Messaging as a powerfult alternative based on simple principles, but hard to implement, test and tune. On Fri, 28 Jun 2002 10:34:57 +0800, Ben Kloosterman <[EMAIL PROTECTED]> wrote: >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. 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.
