In section Theory. Referential data usage specifics we have mentioned that the platform has a cache that stores object data read from the database. Now we will discuss this feature in more detail.
1C:Enterprise caches database objects that are read from the database using object operations.
When you access object attributes using a reference, the platform accesses the object cache that is stored in RAM.
The object cache consists of two parts: the transactional cache and the standard cache. Which cache is used depends on whether the reference is made in the context of a transaction or not (fig. 14.33).
Fig. 14.33. Object cache
All the data stored in the cache is intended to be read-only. This means that all the data that is read by reference is handled using the object cache, while writing is handled using 1C:Enterprise object operations.
If the required data is not found in the standard cache, the object data is read from the database and stored to the cache. In this case a reference to the database object serves as the unique identifier for the cache. Therefore, the data for each read object can exist in the cache in one of two forms: either all the object data, or an object presentation.
This means that if you access the cache to get an object presentation, and the cache contains data for the specified reference, that data is taken from the cache (if the entire object is in the cache, the required presentation is taken from the object data).
If the cache does not contain data for the specified reference, only the fields required to generate the object presentation are read from the database.
If you access the cache to get an object attribute, and the cache contains data for the specified reference, what comes next depends on the cache contents.
If the cache contains the entire object, the attribute value is read from the cache. If the cache contains object presentation, the presentation is deleted from the cache and then all the object data is read from the database and stored to the cache. If the cache does not contain data for the specified reference, all of the object fields are read from the database.
The read data remains in the cache until one of the following events occurs:
- The read data is forced out of the cache by read data that belongs to other objects (cache overflow).
- The next time you access the cache it turns out that the read data has been modified in the database.
- The 20-minute timeout expires.
All the read data is kept in a sequential queue and, since the cache size is limited, the oldest data in the cache is replaced by the most recent data.
Upon subsequent calls for data that has already been read into the cache, the platform checks the elapsed time since the data entered the cache.
If the call is within 20 seconds after the data arrived, the data is considered valid. If the elapsed time is longer than 20 seconds, the platform checks that the version of the data stored in the cache matches the version in the database.
If the data versions do not match (the data in the database has been changed), the data is deleted from the cache and reread from the database. The next 20-second data validity period is counted from that point.
In addition to the listed events, read data is deleted from the cache 20 minutes after it was last read from the database.
So if you execute two operators in sequence (listing 14.43) where MaterialOrService is a reference to a catalog item, the execution of the second line takes much less time because the execution of the first line includes a database query while the execution of the second line only includes reading data from RAM (from the object cache).
Listing 14.43. Operator sequence
A = MaterialOrService.Description; B = MaterialOrService.MaterialServiceType;
If data is accessed in the context of a transaction, the request is redirected to the transactional cache. In 1C:Enterprise all the operations related to data modifications in the database are executed within transactions. For example, a document posting event handler is executed within a transaction.
A transaction is an indivisible sequence of data manipulations that brings the database from one integral state to a new one. So if for some reason one of the transaction operations cannot be accomplished, the database returns to the state it had before the transaction (transaction rollback).
The transactional cache is essentially the same sequential queue as the standard cache. The difference is that all the data in the transactional cache is definitely valid (up-to-date).
When the platform reads data to the transactional cache, it locks the data in the database, so there is no way it can be changed until the transaction is complete.
The transactional cache stores read data until it is replaced by subsequently read data or until the transaction is completed. Upon completion of a transaction, the cache is cleared while the actions performed at the moment of clearing depend on the completion status of the transaction.
If the transaction is successfully completed (committed), the data of all the objects in the transactional cache is moved to the standard cache and the transactional cache is cleared (fig. 14.34).
Fig. 14.34. Successful completion of a transaction
If the changes are canceled (rolled back), they are simply cleared from the transactional cache (fig. 14.35).
Fig. 14.35. Clearing transactional cache upon rollback