The CyberStore application employs various techniques designed to cache information commonly used by the system. Caching allows for the temporary storage of certain data in an alternate storage location making the data more readily available to the program than it is in its natural location. By taking advantage of this technique, system performance is improved which results in a better end-user experience for the shopper. 

Types of Caching Used by CyberStore

As stated previously, CyberStore employs several different caching techniques, each with their own nuances and advantages. The first thing to determine when employing a cache is what you are trying to store in an alternate location, and then where is the best place to store it. Considerations include proximity to the application, speed of access, volatility of the data (that is how often will it need to be updated) and where is the best location to store it. Fundamentally speaking, all caches should be as close to the application as possible and constructed with as simple a structure as practical. CyberStore cached data is stored in one of two locations - the CyberStore application's web server memory,  or the CyberStore database.

Memory Caches

Server memory provides the best response time when the data stored is needed, but is the most limited in terms of available space, and it's life is finite. Memory cache space can be used up, so it needs to be managed to ensure that older data can fall away as new data needs space that was previously taken.

Memory caching techniques employ the following constructs - environment cache, application variables and session variables. All of these constructs allow for the storage of any type of object, and have a specific life expectancy to their data. In addition, the scope of their data is different. No matter the type of memory cache used the information stored in them is either a logical object constructed by the program, or a data object whose natural location is in a database or external system. In either situation computing or receiving the construct once, saving it in memory, and thereafter accessing it instantly will dramatically improve application performance.

Environment Cache

Environment cache (or technically speaking the System.Web.HostingEnvironment.Cache or System.Web.HttpContext.Current.Cache, they're the same thing) is the most robust memory cache, and is specifically designed in .NET for caching, and has built in methods for handling the time to live for a cached entity , the ability to roll off older data as newer data is needed to cache, and managing the amount of memory it uses. The environment cache is tied to the application pool and can only exist while its related pool is alive.

Environment Cache Entity	Description	Where Managed
SYSPRO e.net responses	Full response XML from e.net queries and posts to SYSPRO	SYSPRO Configuration
Single Item Information	Data from the database's Item View List View by ViewList as a DataRow	Item Maintenance View List Maintenance

Application Variables

Application variables are an available dictionary of key and value pairs that allows the programmer to create entries at will. They can then be read, changed or emptied like any variable value. They are often  populated at the onset of a new application pool starting, and then emptied and repopulated as needed. Like environment cache, the lifespan of an application variable cannot survive past the life of its related application pool.

Application Variable Entity	Description	Where Managed
Common Configuration (ComConfig)	Settings for Sites.	Site Manager
SYSPRO Configuration (ComConfigSyspro)	Settings for SYSPRO integration.	SYSPRO Configuration
Default Site	Default Site settings.	Database
Item Characteristic Values	All values for all Item Characteristics.	Item Characteristic Maintenance Application Settings
Item Characteristic Definitions	Characteristic settings for Items.	Characteristics Grid
SitePages	SitePages.config files transformed into SitePages object for all Sites.	SitePages.config XML files

Session Variables

Session variables, like their application counterparts, are also a dictionary of key and value pairs able to be maintained in the same way, however their context is tied to an individual, and unique visitor session storing different values of the same entity with values relevant to the session. Session variables can be populated  at the start of a session, or managed individuality during as the program may require. Since a session will cease to exist if the application ends, these too cannot live when the application pool stops or restarts but unlike the application variable, they will not persist beyond the end of the session they are tied to.

Session Variable Entity	Description	Where Managed
User ID	The ID of a logged in Shopper's Account.	Database.
User Data	Combination of key Account and Customer data for the current Shopper.	Account Maintenance. Customer Maintenance. Customer Class Maintenance.
User Name	Login for the currently logged in Shopper.	Account Maintenance
User Company	Company Name for the Customer of the logged in Shopper.	SYSPRO Customer Maintenance
User Customer Number	Customer Number for the Customer of the logged in Shopper.	SYSPRO Customer Maintenance
View List ID	The ID of the View List for the current Shopper.	Database.
Site ID	The ID of the current Site.	Database
Settings	Common Configuration settings for the current Shopper's Site.	Site Manager
SYSPRO Settings	SYSPRO Configuration for the current Shopper.	SYSPRO Configuration.

Database Caches

While not as efficient as memory caches, utilizing a database to cache semi-permanent data can provide excellent performance with simple queries, even when large amounts of data is stored (and best when the data is indexed well for its intended usage). This is especially true when the database server proximity is closer to the application server than an otherwise definitive data source's natural location.

When complex data is requested from an external system, that system's processing must take place prior to sending information, and the information received is typically very verbose in nature which requires potentially complex interpretation by the program. When combined with distance this scenario adds three layers of latency to accessing the data - distance, computational overhead, and data complexity - simplifying the results of such requests and transforming the data to simpler constructs to be stored in a well designed database will provide for better performance in almost all cases.

Unlike the types of memory caches described previously, caching here has the advantage of persistence. Information in the database remains stable and exists beyond an application pool or session, and in fact can persist permanently if so desired.

Database Cache Entity	Description	Where Managed
Items	Base information about items such as stock code, description, units of measure, etc.	SYSPRO Stock Code Maintenance.
Customers	Base information about Customers such s Customer Name, Number, Addresses, etc.	SYSPRO Customer Maintenance.
Customer Pricing	Default, Customer, Discount, Web and Line prices by Item for Customer in a specified quantity per unit of measure.	SYSPRO Pricing. CyberStore Item and Category Discounts Tools > Application Settings
Available to Promise (ATP)	Calculated ATP data.	SYSPRO Available to Promise.