Rest API Stateful

[SBarnes]

I've been having a look at how state is handled in the REST api and from what I can see it is handled by the ObjectDictionary on the manger, which seems simple enough, my question is this what happens if stateful requests aren't abandoned, my reason for asking is I need to create a two route process one where a list of information will be retrieved and another where that same list will be posted back to the api and then changes will happen based upon how the items are changed in the second request.

Whilst I could create the list a second time I would prefer not to as this will be reasonably database intensive and plucking it out of the ObjectDictionary would be easier but my question is what about if the second call never happens are things going to chew up memory or is the ObjectDictionary cleaned up when a sessions ends i.e. the manager is logged off and the ObjectDictionary cleared?

By the way when using an api key should you still explicitly call logout regardless of using state?

[Mike.Sheen]

what happens if stateful requests aren't abandoned

They stay in memory until the session has expired, and a request triggers a cleanup of expired sessions - that will dispose of the Manager associated with the session and thus the objects in the ObjectDictionary.

Any request at all - even for a different session will cause a cleanup of all expired sessions. This can be seen in the REST API plugin code:

Code: Select all

AppHost.GlobalRequestFilters.Add((req, res, requestDto) => {
   // find all expired and log off
   var expiredSessionCleanupTask = System.Threading.Tasks.Task.Run(() =>
   {
      ServiceStack.Caching.ICacheClient cache = HostContext.TryResolve<ServiceStack.Caching.ICacheClient>();
      var sessionKeys = cache.GetKeysStartingWith("urn:iauthsession").ToList();
      IDictionary<string, JiwaAuthUserSession> currentSessions = cache.GetAll<JiwaAuthUserSession>(sessionKeys);

      //allSessions will contain a list of all current non-expired sessions.  We need to find all the entries in the JiwaSessionDictionary which
      //are not in the allSessions dictionary and log them off.
      var expiredSessions = RESTAPIPlugin.JiwaSessionDictionary.Keys.Where(x => !currentSessions.ContainsKey("urn:iauthsession:" + x));
      foreach (string expiredSessionId in expiredSessions.ToList())
      {
         JiwaFinancials.Jiwa.JiwaApplication.Manager sessionManager = null;
         RESTAPIPlugin.JiwaSessionDictionary.TryGetValue(expiredSessionId, out sessionManager);

         if (sessionManager != null)
         {
            sessionManager.LogOff();
            RESTAPIPlugin.JiwaSessionDictionary.Remove(expiredSessionId);
         }
      }
   });


Whilst I could create the list a second time I would prefer not to as this will be reasonably database intensive and plucking it out of the ObjectDictionary would be easier but my question is what about if the second call never happens are things going to chew up memory or is the ObjectDictionary cleaned up when a sessions ends i.e. the manager is logged off and the ObjectDictionary cleared?

How much memory used all depends on the length of your configured session expiry, and how many different sessions will be servicing those requests. Only way to know is to measure in production - add some logging perhaps of the sessions in-memory and also how much memory the current process (Self-hosted API Service) is using.

By the way when using an api key should you still explicitly call logout regardless of using state?

I don't bother - I always let the session expiry take care of API key logouts.

[SBarnes]

Thanks Mike

By the way when using an api key should you still explicitly call logout regardless of using state?

I don't bother - I always let the session expiry take care of API key logouts.

Given this is a site that has high volumes and has had issues with connection pooling on the database before with the api, I think from that you know who I am talking about I am going to insist they logout as I would like to avoid this in production.

It's going to be hard enough juggling multiple sales orders in one call for what needs to be done.