EF Core Second Level Cache Interceptor

To use the interceptor effectively, follow these guidelines:

• Selection Criteria: Cache global site settings, public data (e.g., articles, comments), or user-specific data that changes infrequently. Avoid caching small, frequently changing per-user data; use alternatives like user claims in cookies instead.
• User Scoping: The cache is application-scoped, not user-scoped. It does not use session variables. To cache per-user data safely, you must include a user ID filter in your query, such as .Where(x => x.UserId == id).
• Invalidation: The cache automatically updates when entities are inserted, updated, or deleted via a DbContext using this interceptor. Note that modifications made outside the interceptor (e.g., stored procedures, triggers, or other applications) will result in stale cache data.
• Transactions: By default, queries inside an explicit transaction (context.Database.BeginTransaction()) are not cached. However, CRUD operations within that transaction will still trigger cache invalidation. To enable caching within transactions, use .AllowCachingWithExplicitTransactions(true).
• Database Compatibility: If your database provider lacks support for types like DateTimeOffset or TimeSpan, you must configure EF Core [value converters] in your DbContext to handle these types.

Automatic Invalidation

The interceptor automatically invalidates cache entries when SaveChanges() or SaveChangesAsync() is called. It detects which tables were modified and clears dependent cached queries.

Warning: Bulk operations like ExecuteUpdate and ExecuteDelete bypass EF Core interceptors and will not trigger automatic invalidation. You must invalidate these manually.

Manual Invalidation

Inject IEFCacheServiceProvider to manage the cache manually:

• Clear everything: _cacheServiceProvider.ClearAllCachedEntries();
• Invalidate specific tables: Use _cacheServiceProvider.InvalidateCacheDependencies(new EFCacheKey(tableNames)) where tableNames includes the prefixed table names (e.g., EF_TableName).

Invalidation Notifications

You can hook into invalidation events using .NotifyCacheInvalidation(action) during service registration to log or react to cache clears.

// Manual invalidation example
var tableNames = new HashSet<string> { "EF_TableName1", "EF_TableName2" };
_cacheServiceProvider.InvalidateCacheDependencies(new EFCacheKey(tableNames));

You must register the second-level cache services in your Startup.cs or Program.cs and then add the SecondLevelCacheInterceptor to your DbContext registration using dependency injection.

1. Register Services: Use AddEFSecondLevelCache to configure your provider (e.g., UseMemoryCacheProvider).

2. Add Interceptor to DbContext: When configuring your DbContext (e.g., via AddDbContextPool), use .AddInterceptors() and retrieve the SecondLevelCacheInterceptor from the IServiceProvider.

// 1. Register Services
services.AddEFSecondLevelCache(options =>
    options.UseMemoryCacheProvider()
           .ConfigureLogging(true)
           .UseCacheKeyPrefix("EF_")
           .UseDbCallsIfCachingProviderIsDown(TimeSpan.FromMinutes(1))
);

// 2. Add Interceptor to DbContext
services.AddDbContextPool<ApplicationDbContext>((serviceProvider, optionsBuilder) =>
    optionsBuilder
        .UseSqlServer(connectionString)
        .AddInterceptors(serviceProvider.GetRequiredService<SecondLevelCacheInterceptor>()));

You can define rules to skip caching for specific queries based on their SQL command text or the resulting data. This is useful for queries that are highly dynamic or return data that shouldn't be stored.

• Skip by Command Text: Use SkipCachingCommands to provide a predicate that inspects the SQL command string.
• Skip by Result: Use SkipCachingResults to provide a predicate that inspects the query result. You can check for null or use EFTableRows to check the RowsCount.
• Using Query Tags: Instead of using the .NotCacheable() extension method, you can use EF Core's .TagWith("tag-name") method. This adds a comment to the SQL. You can then configure SkipCachingCommands to look for that specific comment string.

// Skip by command text
services.AddEFSecondLevelCache(options =>
{
    options.SkipCachingCommands(commandText =>
        commandText.Contains("NEWID()", StringComparison.InvariantCultureIgnoreCase));
});

// Skip by result
services.AddEFSecondLevelCache(options =>
{
    options.SkipCachingResults(result =>
        result.Value == null || (result.Value is EFTableRows rows && rows.RowsCount == 0));
});

// Using Query Tags
// 1. Tag the query in EF Core
var blogs = await context.Blogs
    .TagWith("Fetching data")
    .Where(b => b.IsActive)
    .ToListAsync();

// 2. Configure skip rule based on the tag
services.AddEFSecondLevelCache(options =>
{
    options.SkipCachingCommands(commandText =>
        commandText.Contains("-- Fetching data", StringComparison.InvariantCultureIgnoreCase));
});

You can use EasyCaching.Core as a highly configurable cache manager. You can use it with In-Memory or Redis providers. For multi-tenancy, you can provide a delegate to UseEasyCachingCoreProvider that selects a provider name dynamically based on the current context (e.g., a tenant ID from IHttpContextAccessor).

```csharp
// Example: In-Memory with EasyCaching.Core
const string providerName = "InMemory1";
services.AddEFSecondLevelCache(options =>
    options.UseEasyCachingCoreProvider(providerName, isHybridCache: false)
           .UseCacheKeyPrefix("EF_")
);

services.AddEasyCaching(options =>
{
    options.UseInMemory(config =>
    {
        config.DBConfig = new InMemoryCachingOptions { SizeLimit = 10000 };
        config.MaxRdSecond = 120;
    }, providerName);
});

// Example: Dynamic Provider for Multi-tenancy
services.AddEFSecondLevelCache(options =>
    options.UseEasyCachingCoreProvider(
       (serviceProvider, cacheKey) => "redis-db-" + serviceProvider.GetRequiredService<IHttpContextAccessor>().HttpContext.Request.Headers["tenant-id"],
       isHybridCache: false)
);