Unity Script Caching

[Adam_Ryman]

Unity Script Caching

In OnBase, Unity Scripts are cached to increase performance. To run a script the Unity API Script framework will pull down script info, reference information, assembly data, as well as pdb files all from the database. It will also pull down the assembly information for all references. To avoid constant database requests and in turn increase performance, we cache the information to make it more easily accessible.

Server Cache vs. Client Side Cache

OnBase has a plethora of different unity script projects (interfaces). Some of these scripts will execute client side within the Unity Client, where some of these scripts will execute server side on the Application Server. Depending on where a script executes will influence where the script is cached.

Server Side Cache

Unity Scripts leverage the .NET Framework to create an application domain specifically for Unity Scripting. Per MSDN: "Application domains provide an isolation boundary for security, reliability, versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run." The Unity API has its own app domain that is associated with the OnBase Application Server. This app domain serves as a server side cache for Unity API Scripts. If we make changes to a server side script, the Unity API Application Domain will need to be cleared. That is, the server side cache needs to be reset.

How is the server side cache reset?

OnBase Studio provides the means for properly resetting the server side cache. While an application pool recycle or IISReset would reset the server cache, resetting a server in production in the middle of a business day is not always practical. Since the API has its own app domain on the server, we can explicitly reset the Unity API App Domain and therefore update/create scripts without affecting the rest of the OnBase system. There have been some noticeable differences in the way that we reset the server cache for Unity Scripts over the past few versions.

OnBase 14

In OnBase 14, after creating/modifying a script, the cache is updated by clicking the "Reset Server Cache" button on the home tab within OnBase Studio. Keep in mind this could take up to 60 seconds for the cache to reset. This marks an internal database flag, which is checked every 60 seconds.

OnBase 15

In OnBase 15, we found a defect that would leak app domains and cause memory exceptions on the server. We changed the software so that when server cache reset button is clicked in OnBase Studio, it no longer flags the database to tell IIS to reset the app domain. We instead tell IIS to kill the app domain on the action of setting a Unity Script to active. Therefore, in OnBase 15 activating a Unity script will cause the current app domain to be destroyed and cause IIS to rebuild that app domain with the active script from the database. To put it more simply, in OnBase 15 setting a script as active will clear the server side cache. This change was also backported to later versions of OnBase 14.

OnBase 16+

In OnBase 16, we added new functionality. After a script is created/modified and set as 'Active', the developer is prompt to reset the server cache immediately. Under the circumstance the developer would decide to reset the server cache later, the “Reset Server Cache” button on the home tab will still clear the cache. Keep in mind this could take up to 60 seconds for the cache to reset. This marks an internal database flag, which is checked every 60 seconds.

Client Side Cache

The Client Side cache is stored client side within the OnBase Unity Client. If a script runs client side, the Unity Client will check its local cache to look for the assembly at runtime.

Resetting Client Side Cache

Resetting the cache client side is a very simple task. The Unity Client cache is cleared out every time the Unity Client is closed. Therefore if we connect to a new instance of the Unity Client and run a client side script, this will cause a new cache of the script to be pulled down. If we have the Unity Client open when the script is updated, we will need to reset the Unity Client. This will not require any server cache resets.

In Closing

If you ever find yourself making script modifications, but your script changes are not being reflected in the business process, always be sure the cache is up to date. If this is a server side script, clear up the cache from within OnBase Studio. If this is a client side script, be sure to restart the OnBase Unity Client.

Next week the topic for discussion is C# 6 in OnBase Studio.  Look forward to it!