Datarabbit lightweight data access framework (20) -- real-time Synchronized entity cache syncentitycache

In the system architecture design, cache is the most common strategy to reduce database load and improve performance. The main purpose of cache is to reduce the numberReadOperation. But in different cases, we need to use different forms of cache.

For example, if the data in the data table is static and does not change, it is very easy. We only need to load the data to the memory when the system starts, you can read data from the memory each time.

For another example, the data in the data table will change (add, delete, and modify), but the change frequency is very low, and our system is not very sensitive to real-time data, then we can use the cache refreshed regularly. datarabbit also has built-in support for this cache. For details, see datarabbit's lightweight ORM framework (16)-entity cache.

For example, if there are many records in the data table and only insert operations are performed for modification, we can use hotcache to cache frequently used records in the memory and set the timeout mechanism. Hotcache will be introduced later.

For another example, a data table is often modified by insert and update operations. However, no matter how update is performed, the values of some fixed columns in each record will not change, then we can encapsulate these unchanged columns in a sub-object, and then cache these sub-objects in the memory.

Given so many examples, we are now going to the point of this article, assuming that the data in a certain data table will change (add, delete, and modify), but the change frequency is relatively low, however, our system is extremely sensitive to the real-time data in this table. At this time, we need to use the [real-time Synchronized entity cache ], the cached data is exactly the same as the data in the data table at any time.

Syncentitycache in datarabbit is such a cache.

Of course, there is a premise that such real-time synchronization cache must be ensured, that is, modifications to the target data table must be made through syncentitycache, which should be relatively easy to guarantee.

Let's take a look at the content of the isyncentitycache interface:

This interface has two generic parameters: tpkey and tentity. tpkey indicates the type of the primary key of the data table, and tentity indicates the type of the target entity.

The three attributes are:

Transactionscopefactory indicates the database in which the target data table is located.

Pkeyname is the name of the primary key column.

Pkeyautoincreased indicates whether the primary key is of the auto-increment type.

However, the entity that can be cached must implement the isynccachedentity interface:

The GETID () method of the base interface icachedentity is used to return the value of the primary key field of the entity. Isynccachedentity inherits the icloneable interface, indicating that entity must be replicated. The reason for inheriting this interface will be described later.

 

When the system starts, we call the initialize method to load all records of the target table from the database. Then we can use the getentitycopy () method and getentitycopylist () method to read the required entity. Note that the names of these two methods contain "copy", indicating that they will return a copy of the cached entity. Therefore, even if you modify the returned copy, it does not affect the entity in the cache.

Obviously, the efficiency of the two methods will be slightly reduced because of the clone of entity. However, if youGuaranteedThe read entity is only used for read, so you can call the getentitylist4read () method, which is more efficient and will directly return the entity in the cache.

In addition, you can see that isyncentitycache provides basic addition, deletion, and modification methods. We must call these methods to modify the records in the target data table, these methods automatically synchronize the entity in the cache to make it consistent with that in the database.

Finally, isyncentitycache provides the reload () method, which is used when the records in the target data table are accidentally modified (that is, the modification is not performed through isyncentitycache ), manually refresh the cache to obtain full consistency with the data in the database.

Datarabbit. application. cache. syncentitycacheClass implements the isyncentitycache interface, and this implementation is thread-safe, you can safely use it in a multi-threaded environment.

 

Datarabbit3.0 and later versions fully support the above policies. You can download the latest version.

For more information about datarabbit directories, see here.