This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I'm evaluating Lightspeed and after reading the docs, browsing the site and trying out a few things manually I've come to the following conclusions about the cache mechanisms. Please correct any of the following statements which are wrong. - The L1 cache is always active and isn't affected by the [Cached] attribute. - Such attribute only affects the L2 cache and the ExpiryMinutes parameter is honored by both L2 cache providers that come with Lightspeed. Which target System.Web.Caching.Cache and Memcached. - If the ExpiryMinutes parameter isn't specified Memcached will purge its cache indipendently according to its own configuration file. - The L1 cache is write-through, meaning that if I modify or delete an entity which is already stored in it the L1 cache will correctly reflect that.
I also have a couple of questions. - If the ExpiryMinutes parameter isn't specified for how long will the entity remain in memory if using the L2 cache provider that targets System.Web.Caching.Cache? - In the documentation you say that usage of L2 cache should be pondered appropriately since it might result in fetching stale entity data. However from my tests the L2 cache (at least using the provider targeting System.Web.Caching.Cache) seems to be write-through. If I update or delete an entity that was already stored in the L2 cache such cache is properly updated and I don't get stale data. Maybe the stale data problem arises only with the Memcached provider which perhaps isn't write-through?
|
|
|
Most of your first four statements are correct. We actually think of the L1 cache less as a cache and more as an identity map, but you're right to identify that is has cache-like behaviour. However, if you don't specify an ExpiryMinutes parameter then both the Web and Memcached caches will use 15-minute expiry times. I.e. your statement about using the Memcached configuration file is *not* correct. I believe it should be possible to work around this by writing a custom cache provider on top of Memcached -- this should be only a few lines of code and we'd be happy to help if required. Yes, the L2 cache is write-through. The warning against stale data is that the data may not have been refreshed recently from the database. For example, suppose Machine A and Machine B both load Widget #2 into a unit of work, and Machine A then updates and saves Widget #2. This updates the L2 cache on Machine A but not on Machine B. Now Machine A creates a new unit of work and loads Widget #2. This hits the Machine A L2 cache so it gets the updated version. Machine B also creates a new unit of work and loads Widget #2. If there were no L2 cache, this would cause the entity to be reloaded from the database, but as it it, it hits the Machine B L2 cache, which still contains the pre-update version. Hope that makes a bit more sense now! |
|
|
By the way, if you've not seen this article about caching, you might find it worth a look: http://www.mindscape.co.nz/blog/index.php/2009/11/05/whats-the-deal-with-lightspeed-caching/ |
|
|
Ivan, thanks for your replies. Just to make sure I got this right:
[quote user="ivan"]Yes, the L2 cache is write-through. The warning against stale data is that the data may not have been refreshed recently from the database. For example, suppose Machine A and Machine B both load Widget #2 into a unit of work, and Machine A then updates and saves Widget #2. This updates the L2 cache on Machine A but not on Machine B. Now Machine A creates a new unit of work and loads Widget #2. This hits the Machine A L2 cache so it gets the updated version. Machine B also creates a new unit of work and loads Widget #2. If there were no L2 cache, this would cause the entity to be reloaded from the database, but as it it, it hits the Machine B L2 cache, which still contains the pre-update version.[/quote]
That's right, but if the L2 cache is a memcached one and it's placed on, say, Machine C no issues would happen with stale data, right? |
|
|
Yes, you're correct that the stale data issue would go away with a memcached L2 cache (assuming all the machines are hooked up to the same distributed/remote cache). |
|