v6 objects are now tied to one and only one scope - cannot be used in a singleton cache?

[swegele]

or in any other scenarios where multiple scopes are involved...

Why? If I am right, because all CSLA objects now contain a scoped ApplicationContext reference which contains an IServiceProvider. This IServiceProvider belongs to the scope that fetched the object and that gets disposed when that user logs off.

Background: I'm happily converting piece by piece of our legacy WebForms app (CSLA 5.2) to our shiny new Blazor Server Side app using CSLA 6 :-) Today I migrated over the ApplicationCache mechanism. It used to be a static class living in Application scope on web server. Now it is an injected singleton service in Blazor. It simply stores various readonly lists of objects fetched frequently for lookups and tracks when it should be fetched fresh.

Trouble is, the first user to fetch a list populating the cache used their ApplicationContext for the Fetch. Now that user logs off.
Then a different or same user logs in (gets a new scope) and they access the cached list and get one object.
What happens when they hit a getter on a property for the ReadOnly object?

[2022-09-15T00:05:34.811Z] Error: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'IServiceProvider'.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Csla.Core.ApplicationContextAccessor.GetContextManager()
   at Csla.ReadOnlyBase`1.VerifyAuthorizationCache()
   at Csla.ReadOnlyBase`1.CanReadProperty(IPropertyInfo property)
   at Csla.ReadOnlyBase`1.CanReadProperty(IPropertyInfo property, Boolean throwOnFalse)
   at Csla.ReadOnlyBase`1.GetProperty[P](PropertyInfo`1 propertyInfo, NoAccessBehavior noAccess)
   at BL.Agency.AgencyInfo.get_AgcStatus() in C:\Repos\LIMS-plus\BL\Agency\AgencyInfo.cs

The return GetProperty(AgcStatusPropertyInfo).Trim(); on the property triggers the deeper framework code which ends up trying to access the IServiceProvider which is gone/disposed.

After pacing around my house for several hours, I'm wondering if I am correctly realizing that CSLA objects (because of the nice happy new dependency injection underpinings) must now absolutely always:

• only be used in the same scope in which they were fetched
• cannot be stored in a singleton and/or used by other scopes

@rockfordlhotka Please advise - and prepare for me to go find the nearest tall bridge (luckily I live in a desert with no bridges nearby so I will likely die of thirst first walking to find one).

[swegele]

FYI - just for giggles I went into one of the ReadOnly classes and changed all the GetProperty statements to ReadProperty. Then I repeated the login/fetchcache/logoff/login/fetchcache action and the error is gone because the underlying framework code to check permissions isn't being triggered now in the objects that were fetched by the initial scope.

Worth mentioning that none of the ReadOnly objects that go in the Singleton cache have any security to them.... they are just lookup objects / lists that anyone can fetch. So technically I could make all the gets reads, but this feels like a deeper problem that I will bump into elsewhere.

Brainstorming for possible solutions:

1. Obvious one is to get rid of singleton cache and just have a cache per scope. Ugh. Better than nothing but not quite the memory/speed saver I had in CSLA 5. But it would be simple to implement...simply change the Program.cs to register the Cache as scoped service.

2. Another option is to not do singleton cache of Csla objects but instead use POCOs. Again Ugh. That would involve huge code changes.

3. Another option is if you abstracted the methods LocalProxy.SetApplicationContext out of that class and exposed them publicly somewhere generically so we as business object coders could purposely swap the AppContext in an object that is being passed to another scope.
   Then my singleton cache could be altered to give cloned objects (with appropriate appcontext) out to callers. I think this would still be a perf gain over every scope fetching it's own cache.
   In essence...it's the exact same thing you are doing in LocalProxy...just making it so we can do it too. Is that terrible?

[rockfordlhotka]

You are correct, each object graph does maintain a reference to the scope that created the graph, which is necessary because various features like rules and the data portal require the use of the scope (or at least ApplicationContext, which is scoped).

When a stream is deserialized into a graph, that graph is given the ApplicationContext for the scope into which it is deserialized. As a result, you should be able to cache the serialized graph, and deserialize that stream from the cache when necessary. Basically cloning.

To do this, use MobileFormatter directly to serialize the graph into a stream and back out again.

[swegele]

Thanks Rocky!! The MobileFormatter suggestion was the trick. I refactored things on a Set cache method to immediately serialize to a byte array and stick it in an IDistributedCache and then for the Get method I am able to use DI to get the scope's ApplicationContext and to deserialize and give it safe to the user that asked for it. Works like a charm.

I will need to remember to pay attention to any other areas that end up cross-scope in nature while interacting with Csla BOs.

[saulyt]

Would it be possible to provide a code sample of what you did? I'm working on something similar and would like to see how it's done.

[swegele]

Sure...happy to help. Go easy on me because "as-is-no-guarantee" etc etc. regarding the quality of this solution :-)

Program.cs
builder.Services.AddDistributedMemoryCache(); //use whichever implementation you need

Start with a generic class that is an applicationcacheitem wrapper

    /// <summary>
    /// Strongly typed wrapper class, used by <see cref="ApplicationCacheService"/>, managing cached items expiry time, fetch logic, clearing the item, etc.
    /// </summary>
    /// <typeparam name="T">Type of object that is stored/managed by this wrapper</typeparam>
    internal class ApplicationCacheItem<T>
    {
        #region Variables

        private readonly int _ExpiryMinutes;
        private readonly Func<T> _GetObjectFunction;
        public readonly string _UniqueName;
        private readonly ApplicationContext _ApplicationContext;
        private readonly IDistributedCache _IDistrubutedCache;

        #endregion

        #region Constructors

        //default constructor pull value from config for expiry minutes
        internal ApplicationCacheItem(Func<T> setCacheMethod,
            AppSettings appSettings,
            ApplicationContext applicationContext,
            IDistributedCache iDistrubutedCache,
            string uniqueName)
        {
            _UniqueName = uniqueName;
            _GetObjectFunction = setCacheMethod;
            _ExpiryMinutes = appSettings.AppCacheExpireMinutes;
            _ApplicationContext = applicationContext;
            _IDistrubutedCache = iDistrubutedCache;
        }

        //special constructor accepts manually configured expiry minutes (used to set expiry to longer value than default to lighten the load of fresh lookups for slow changing items)
        internal ApplicationCacheItem(int expiryMinutes,
            Func<T> setCacheMethod,
            ApplicationContext applicationContext,
            IDistributedCache iDistrubutedCache,
            string uniqueName)
        {
            _GetObjectFunction = setCacheMethod;
            _ExpiryMinutes = expiryMinutes;
            _ApplicationContext = applicationContext;
            _IDistrubutedCache = iDistrubutedCache;
            _UniqueName = uniqueName;
        }

        #endregion

        #region Methods

        /// <summary>
        /// This method sets the cache object to null which will force a fresh lookup next time it is referenced
        /// </summary>
        internal void ClearTheCache()
        {
            _IDistrubutedCache.Remove(_UniqueName);
        }

        /// <summary>
        /// This method handles getting the cache object and monitoring the refresh timer for when to get fresh data
        /// </summary>
        /// <returns>The object that this cache item manages</returns>
        internal T GetObject()
        {
            T cachedObject;
            var bytesFromCache = _IDistrubutedCache.Get(_UniqueName);

            if (bytesFromCache == null)
            {
                //fetch object
                cachedObject = _GetObjectFunction.Invoke();

                //serialize it into byte[]
                using (var memStream = new System.IO.MemoryStream())
                {
                    var mf = new MobileFormatter(_ApplicationContext);
                    mf.Serialize(memStream, cachedObject);
                    memStream.Position = 0;
                    bytesFromCache = memStream.ToArray();
                }

                //put it into cache
                _IDistrubutedCache.Set(_UniqueName, bytesFromCache, new DistributedCacheEntryOptions()
                {
                    AbsoluteExpirationRelativeToNow = new TimeSpan(0, _ExpiryMinutes, 0)
                });

                return cachedObject;
            }
            else
            {
                using (var memStream = new System.IO.MemoryStream(bytesFromCache))
                {
                    var mf = new MobileFormatter(_ApplicationContext);
                    return (T)mf.Deserialize(memStream);
                }
            }
        }

        #endregion

    }

Now the scoped ApplicationCacheService

    /// <summary>
    /// Scoped service that gives a scope access to <see cref="ApplicationCacheItem{T}"/> filled with strongly typed object.  This class abstracts the details of the cache away from 
    /// the user/scope (e.g. takes care of getting <see cref="ApplicationContext"/> for any Csla objects and other things like that).
    /// </summary>
    public class ApplicationCacheService
    {
        private readonly AppSettings _AppSettings;
        private readonly ApplicationContext _ApplicationContext;
        private readonly IDistributedCache _IDistributedCache;

        public ApplicationCacheService(AppSettings appSettings,
            ApplicationContext applicationContext,
            IDistributedCache distributedCache)
        {
            _AppSettings = appSettings;
            _ApplicationContext = applicationContext;
            _IDistributedCache = distributedCache;
        }

        /// <summary>
        /// Helper method that takes the MethodBase from <see cref="MethodBase.GetCurrentMethod"/> and makes a string of the DeclaringType and the Name of the Method
        /// "Type_Name" so that we don't have to remember to create unique names manually for each cache item which is buggy and prone to copy/paste errors
        /// </summary>
        /// <param name="methodBase"></param>
        /// <returns></returns>
        private string GetCurrentTypeAndMethodName(MethodBase methodBase)
        {
            return methodBase.DeclaringType + "_" + methodBase.Name;
        }

        #region Cached Items

        internal ApplicationCacheItem<InstrumentInfoList> CacheAllInstruments()
        {
            return new ApplicationCacheItem<InstrumentInfoList>(
                setCacheMethod: () => InstrumentInfoList.GetAll(_ApplicationContext), 
                appSettings: _AppSettings,
                applicationContext: _ApplicationContext,
                iDistrubutedCache: _IDistributedCache,
                uniqueName: GetCurrentTypeAndMethodName(MethodBase.GetCurrentMethod()));
        }

...additional cache items...

        #endregion
    }

Notice the unique name used as the key in IDistrubutedCache is the class name and the method name which obviously must be unique. I did some reading and the overhead for calling MethodBase.GetCurrentMethod() is very minimal (< 1ms). But it is super helpful because other programmers are sure to come along and copy-paste one of your ApplicationCacheItem<T> items and it would be too easy for them to forget to manually create a unique name (remember ye olde session variable key name problem from WebForms).

Now use in a razor component

@inject ApplicationCacheService _appCache;
...

//to fetch/create an item from cache
var instrumentList = _appCache.CacheAllInstruments().GetObject();

//to purposely clear an item from cache (e.g. after user has updated an instrument)
_appCache.CacheAllInstruments().ClearTheCache();

Speed of this bit of serialize/deserialize overhead seems minimal but I haven't done any formal testing yet.

HTH

[saulyt]

Thank you far sharing!

[swegele]

@rockfordlhotka answered above :-)