ServiceStack Ormlite caching entries aren't deleted after expiry - mysql

Question

We are using serviceStack caching with OrmLite Provider (MySql). We noticed that when we create caching keys with expiry dates, the keys don’t get deleted after the expiry date comes. Instead, they get NULL values in the “ExpiryDate” column. Thus, resulting in strange values when we calculate Cache.GetTimeToLive().
Is this a bug in serviceStack or is in our key creating code ? We are using ServiceStack version (4.5.4) and OrmLite version (4.5.4)
IAppSettings appSettings = new AppSettings();
var userConsultsPerHourLimit = appSettings.Get<int>("throttling:consultations:requests:perHourLimit");
var userConsultsPerDayLimit = appSettings.Get<int>("throttling:consultations:requests:perDayLimit");
var userConsultsPerMonthLimit = appSettings.Get<int>("throttling:consultations:requests:perMonthLimit");
var userConsultsMadePerHour = Cache.GetOrCreate<int>(UserConsultPerHourCacheKey, TimeSpan.FromHours(1), () => { return 0; });
var userConsultsMadePerDay = Cache.GetOrCreate<int>(UserConsultPerDayCacheKey, TimeSpan.FromDays(1), () => { return 0; });
var userConsultsMadePerMonth = Cache.GetOrCreate<int>(UserConsultPerMonthCacheKey, (new DateTime(DateTime.UtcNow.Year, DateTime.UtcNow.Month, 1).AddMonths(1).AddDays(-1) - DateTime.UtcNow), () => { return 0; });
string retryAfter = System.Threading.Thread.CurrentThread.CurrentCulture.Name == "ar-SA" ? "يوم" : "day";
bool shouldThrottleRequest = false;
bool didExceedMonthlyLimit = false;
if (userConsultsMadePerHour >= userConsultsPerHourLimit)
{
shouldThrottleRequest = true;
TimeSpan? timeToLive = Cache.GetTimeToLive(UserConsultPerHourCacheKey);
if (timeToLive.HasValue)
retryAfter = Humanizer.TimeSpanHumanizeExtensions.Humanize(timeToLive.Value, 2, System.Threading.Thread.CurrentThread.CurrentUICulture);
}
else if (userConsultsMadePerDay >= userConsultsPerDayLimit)
{
shouldThrottleRequest = true;
TimeSpan? timeToLive = Cache.GetTimeToLive(UserConsultPerDayCacheKey);
if (timeToLive.HasValue)
retryAfter = Humanizer.TimeSpanHumanizeExtensions.Humanize(timeToLive.Value, 2, System.Threading.Thread.CurrentThread.CurrentUICulture);
}
else if (userConsultsMadePerMonth >= userConsultsPerMonthLimit)
{
shouldThrottleRequest = true;
TimeSpan? timeToLive = Cache.GetTimeToLive(UserConsultPerMonthCacheKey);
if (timeToLive.HasValue)
retryAfter = Humanizer.TimeSpanHumanizeExtensions.Humanize(timeToLive.Value, 3, System.Threading.Thread.CurrentThread.CurrentUICulture);
didExceedMonthlyLimit = true;
}

Answer 1

This is working as expected in the latest version of ServiceStack where the row is Deleted after fetching an expired cache entry:
var ormliteCache = Cache as OrmLiteCacheClient;
var key = "int:key";
var value = Cache.GetOrCreate(key, TimeSpan.FromMilliseconds(100), () => 1);
var ttl = Cache.GetTimeToLive(key);
using (var db = ormliteCache.DbFactory.OpenDbConnection())
{
var row = db.SingleById<CacheEntry>(key);
Assert.That(row, Is.Not.Null);
Assert.That(row.ExpiryDate, Is.Not.Null);
}
Assert.That(value, Is.EqualTo(1));
Assert.That(ttl.Value.TotalMilliseconds, Is.GreaterThan(0));
Thread.Sleep(200);
value = Cache.Get<int>(key);
ttl = Cache.GetTimeToLive(key);
Assert.That(value, Is.EqualTo(0));
Assert.That(ttl, Is.Null);
using (var db = ormliteCache.DbFactory.OpenDbConnection())
{
var row = db.SingleById<CacheEntry>(key);
Assert.That(row, Is.Null);
}
We noticed that when we create caching keys with expiry dates, the keys don’t get deleted after the expiry date comes.
The RDBMS doesn't automatically expire Cache Entries by date, but when resolving a Cache Entry the OrmLiteCacheClient will automatically delete expired entries (as can be seen above) so it will never return an expired entry.
Instead, they get NULL values in the “ExpiryDate” column.
This isn't possible. The ExpiryDate is only populated when creating or replacing the existing entry, it's never set to null when it expires. When an entry expires, the entire entry is deleted.

Answer 2

I think we got to the bottom of this .. it was caused by a misuse to the caching APIs from our side .. we found API calls to "Increment" and "Decrement" APIs in different other places causing the keys (those who had exceeded expiry date) to be deleted (by internal call to validate method) and then recreated from scratch (but without expiry date) .. the solution was to call GetOrCreate before calling Increment/Decrement to make sure the key does in fact exist and if it doesn't, recreate it with a fresh expiry date value ..