views:

116

answers:

2

Hello All,

I am tasked with building a process which will compensate for replication delays on our LDAP system. Currently, there is one write server and 4 read servers. After writing an entry to the write server there can be up to a 4 second delay on the system before the entry is replicated to the read servers. Therefore, if I call service "A" which updates a record and then hit service "B" immediately afterwards which is supposed to read that record, the data will be stale.

To resolve this issue I was planning on building a caching web services so that no applications interface directly with the database, but rather through the caching service. The service would store all creates, updates, and deletes in a cache (presumably a List<ModelObject>). The CRUD - R entries would need to remain in the cache for a minimum of four seconds. Then when service "B" attempts to read, the caching service would check the cache prior to performing the read operation on the database.

So, my question is two part. 1) Is this a feasible solution and if not, what problems do you see? 2) How would I do maintenance against the cache within a WCF service. In other words is there a way to initiate a background worker thread that clears entries from the cache that are 4 seconds old?

+1  A: 

Regarding #1, I would say it's feasible, although generating your own caching layer can have it's own difficulties and pitfalls. Off the top of my head I can't think of anything other than you're placing all the load on just one caching server (as opposed to the 4 distributed LDAP servers which can handle the request load).

Regarding #2, I would recommend you check out the Enterprise Library Caching Application Block, I believe it has all the necessary functionality that you need, including scavenging based on time, duration, etc.

Coding Gorilla
Thank you. Solution for #1 will not work because these same LDAP servers are used for both storing customer data (First Name, Last Name, etc), but also for authentication (LDAP binds). A single server would not be able to handle the load from all our users authenticating. However, in thinking about your statement, you've led me to a better solution: Separate the customer data from the authentication system.
regex
+1  A: 

To resolve this issue I was planning on building a caching web services so that no applications interface directly with the database, but rather through the caching service.

Sounds like the right solution to me.

.NET includes several caching libraries to make that easy for you. Here are my favorites:

http://www.infoq.com/news/2010/05/Runtime.Caching http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx

In other words is there a way to initiate a background worker thread that clears entries from the cache that are 4 seconds old?

You don't need to. Just set the expirationTime to (Now+4 seconds) when you add the item to the cache.

But really you shouldn't need a expiration time. If this is the only way to change the values, then it should never expire.

Jonathan Allen