Enterprise Library 4.0 cache application block

Http://msdn.microsoft.com/zh-cn/library/cc511588. aspx

Enterprise Library cache applicationProgramA block allows developers to merge a local cache in an application. It supports in-memory cache, and optional can be database storage or independent back-end storage. The application block can be used without modification. It provides all required functions for obtaining, adding, and removing cached data. Configurable expiration and clearing policies are also part of the Application Block.
When building enterprise-wide release applications, both the architecture and developers have to face many challenges. caching can help them overcome the following challenges:

• Performance. The cache uses the data stored by the user to close the corresponding data as much as possible to improve the performance of the application, which avoids the creation, processing and transmission of duplicate data.
• Scalability. Storing information in the cache helps to save resources and improve scalability when application requirements increase.
• Availability. By storing data in the cache, applications may survive system failures, such as network latency, Web service problems, and hardware errors.

 

Common scenarios
The cache application block applies to the following situations:

• The statement data must be accessed repeatedly or rarely changed.
• Data access is expensive during creation, access, or transmission.
• Data must always be available, even when the source, such as the server is unavailable.

Cache application blocks can be used in the following application types:

• Windows Forms
• Console Application
• Windows Services
• COM + server
• ASP. NET web applications or web services, if the required features are not included in the ASP. NET cache.

The cache application block is deployed in an independent application domain. Each application domain can have one or more caches, either with or without backend storage. The cache cannot be shared in different application domains.
The cache application block optimizes the performance and is thread-safe and exception-safe. You can expand it to include your expiration Policy and backend storage.

Example ApplicationCode
The following code adds an entry to the cache and extracts an entry from the cache. It creates a product-type object and adds it to the cache, there is also a purge priority of 2, a command that does not refresh the entry after the entry expires, and a 5-minute validity period starting from the last access of the entry.

Icachemanager productscache = cachefactory. getcachemanager ();

String id = "productoneid ";
String name = "productxyname ";
Int price = 50;

Product = new product (ID, name, price );

Productscache. Add (product. productid, product, cacheitempriority. Normal, null, new slidingtime (timespan. fromminutes (5 )));

// Retrieve the item.
Product = (product) productscache. getdata (ID );

Highlights of cache application blocks

Application blocks cached by the Enterprise Library include the following features:

• You can use a graphical Enterprise Library Configuration tool to manage configurations.
• You can set a persistent storage location and use an application block that is isolated from the storage or accessed by Enterprise Library Data. Its status is synchronized with the cache in the memory.
• You can expand the application block by creating custom expiration policies and storage locations.
• You can get the guarantee that the application block is executed in a thread-safe way.

 

Determine when to use cached application blocks

The purpose of the cached application block design is to ensure that the application and cache exist in the same system's most common data cache conditions. The cache is local, which means only the application can use it. When it operates as these guidelines, application blocks are ideal solutions for the following situations:

• The cache must be used in different application environments in a consistent manner. For example, by using cached application blocks, developers can write similar code to execute cached application components hosted in Internet Information Service (IIS), enterprise services, and smart client environments. In addition, the same cache configuration options can be used in all environments.
• The scenario requires a configurable and backend storage persistence. The cached Application Block supports both independent storage and database backend storage. Developers can create additional backend storage providers and add them to the configuration settings of the cached Application Block. The application block can also be encrypted before data is cached and saved to the backend storage.
• The scenario needs to change the cache configuration without modifying the application.Source code. Developers first write code using one or more named caches. System operators and developers can use the Enterprise Library Configuration tool to set these named caches.
• Cache items require any of the following expiration settings: absolute time, sliding time, extended time format (for example, midnight every night), file dependencies, or never expire. For more information about expiration settings, see cache expiration design process.
• Developers want to modify the source code of the cached Application Block. For more information about how to modify cached application blocks, see modify application design guide.

In addition, the cache application block provides the same development mode as the application blocks of other enterprise libraries. The cached Application Block is seamlessly integrated with the Data Access Application Block for backend storage. In the same way, secure application blocks, including the cache capabilities provided by cached application blocks. Application blocks configured by developers and operators using the Enterprise Library Configuration tool.

Replace cached application blocks

When multiple applications need to be used, for example, you cannot synchronize cache through web farm. However, if you need to fundamentally change the behavior of the Application Block, you can replace it with a custom class.CachemanagerClass.

Use application blocks to develop applications

Enter cache configuration information

These procedures explain how to configure cache application blocks. The node-related attributes are displayed on the right panel. If you want to use the data access application block as the backend storage, you must configure this application block before configuring the cache application block.
Add application blocks

1. Open the configuration file. For more information, see configure application blocks.
2. Right-click application configuration, point to new, and click cachingapplicationblock.
3. The configuration console automatically adds the cachemanager node with the default settings.

Configure cache manager)

1. Click the caching Application Block node.
2. (Optional) modify the defaultcachemanager attribute name. If the Code does not specify a specific cache manager, the default cache manager is used. Enter a new name or select one from the drop-down list. The default name is cachemanager.
3. Click the cachemanager node (if the cache manager has been renamed, the node will have the assigned name ).
4. (Optional) set the expirationpollfrequencyinseconds attribute. This is the frequency at which the timer controls how often the background scheduler checks for expired entries. The Unit is seconds. The minimum time is 1 second. The default value is 60 seconds.
5. Set the maximumelementsincachebeforescavenging attribute. This is the maximum number of elements that can be cached before being cleared. The default value is 1000.
6. (Optional) Rename the cachemanager node. The default name is cachemanager.
7. Set the numbertoremovewhenscavenging attribute. This is the number of elements removed after the removal starts. The default value is 10.

By default, cache storage entries are only in the memory, and the value assigned to the backend storage is nullbackingstore. You can configure cache application blocks to use database cache storage, independent storage, or custom storage. Database cache storage uses data to access application blocks.
Configure cache application blocks for database cache storage

1. Right-click cachemanager (or the renamed cache manager name), point to new, and then click databasecachestorage.
2. Configure the console to automatically add data access application blocks. For information on configuring Data Access application blocks, see the Data Access Application Block documentation.
3. Click the datachestorage node.
4. Set the databaseinstance attribute. This is the name of the database connection string, which must correspond to the name of a connection string in the data access application block configuration. You can enter a name or select it from the drop-down list.
5. (Optional) Rename the datacachestorage node to set the name attribute.
6. Set the partitionname attribute. This identifies the database part that the cache manager will use.

Configure cache application blocks for independent storage

1. Right-click cachemanager (or the renamed cache manager name), point to new, and then click isolated storage.
2. If you want to encrypt the information stored in the independent storage, right-click isolated storage, point to new, and click encryption Ric storage encryption. Configure the console to automatically add encryption application blocks. For more information about how to configure the encrypted application block, see the document for encrypting the Application Block.
3. (Optional) Rename the isolatedstorage node to set the name attribute.
4. Set the partitionname attribute. This identifies the region of the independent storage that the cache manager will use.

Configure cache application blocks for custom cache storage

1. Right-click cachemanager (or the renamed cache manager name), point to new, and click custom cachestorage.
2. In the attributes attribute section on the right panel, click the ellipsis (...).
3. In the editablekeyvaluecollectioneditor dialog box, click Add to add a new name/value pair.
4. On the right panel of the editablekeyvaluecollectioneditor dialog box, enter the key name and attribute value.
5. Add more name/value pairs, and click OK.
6. (Optional) modify the name of the custom cache storage in the name attribute section on the right panel of the configuration console. The default name is cachestorage.
7. In the type attribute section of the right panel, click the ellipsis. If the required type is not included in the Assembly folder, click loadassembly on typeselector to find the Assembly that contains the required type.

If you want to add another cache and manager instance, right-click the cachemanagers node, point to new, and then click cachemanager to repeat the previous steps. There can only be one default cache manager, and each cache manager must have a unique name.
Instructions for use
The Configuration Setting of the cache application block affects the application's cache usage mode and its system environment, such as the amount of available memory. For example, if an application adds an entry that is much larger than the cache removed when it is cleared (this is a configuration setting) to the cache, the cache continues to grow. Over time, this will cause insufficient memory. Use the performance counters of the Application Block to help adjust configuration settings for each application.

Add application code

Cache application blocks are designed to support the vast majority of data stored in the cache. When adding application code, you need to select the most suitable scenario in key scenarios. Use the Code with the scenario or modify it as needed.

Prepare applications

1. Add a reference to the cache application block. In Visual Studio, right-click the project in solution manager and click Add reference. Click the Browse tab to find the location of the Microsoft. Practices. enterpriselibrary. caching. dll assembly. Select the Assembly and click OK to add the reference.
2. Use the same procedure to set reference to the general assembly of the Enterprise Library, named Microsoft. Practices. enterpriselibrary. Common. dll.
3. Use the same steps to set references to General Assembly of Enterprise Library, Microsoft. Practices. enterpriselibrary. Common. dll, and references to objectbuiler assembly, Microsoft. Practices. enterpriselibrary. objectbuilder2.dll ..
4. If the database back-end storage is used, add a reference to Microsoft. Practices. enterpriselibrary. caching. database. dll and Microsoft. Practices. enterpriselibrary. Data. dll.
5. If you use an encrypted application block to encrypt data in the cache, add a reference to Microsoft. Practices. enterpriselibrary. Security. cryptography. dll and Microsoft. Practices. enterpriselibrary. caching. cryptography. dll.
6. (Optional) Add the following using Statement (C #) to the top of the source code to use elements from the cached application block without fully-qualified element references.

 
Using Microsoft. Practices. enterpriselibrary. caching; using Microsoft. Practices. enterpriselibrary. caching. expirations;
 

Next, add the application code. Generally, two steps are used to create the code for using the cached Application Block:

1. Create a cachemanager object.
2. Call the appropriate method.

Each key scenario demonstrates how to add these steps to the application.

Select backend storage

Each cache manager can be configured to only store data in the memory, which means it uses an empty backend storage; you can also save the data in both the memory and persistent storage. The persistent storage type is specified when backend storage is configured. Backend storage saves cached data when the application must be restarted. In its initial state, the cache application block supports two persistent backend storage types, each of which is applicable to specific situations:

• Independent Storage
• Database cache storage

Developers can extend the cache application block to support other backend storage types. For more information about this topic, see Add a new backend storage.

Use null backend storage
Empty backend storage is the default option for configuring cache application blocks. It does not persist cached entries, which means that the cached data is only stored in the memory and does not exist in persistent storage. Empty backend storage is suitable for Refresh cached entries from the original data source when the application restarts. It can be used for all supported application types. For a list of these types, see Introduction to cache application blocks.
Back-end storage with independent storage
Independent storage is applicable to the following situations:

• Persistent storage and small user volume
• Database usage costs are high.
• No database

For more information about when to use independent storage, see scenarios for isolated storage on msdn, backend storage is isolated by the cache Instance name, user name, application set, and application domain.
Standalone storage is suitable for servers with their own caches on Smart Clients and each application domain. At the same time, note that because the independent storage is always isolated by users, the server application must simulate the user requesting the application.
Use Data to access backend storage of application blocks
Using data to access the application block back-end storage allows you to store cached data in a database. Now, the cache application block contains a script for creating the required SQL Server database mode, and the Application Block has tested the corresponding SQL Server database. Developers can use other types of databases as backend storage, but the source code of the Application Block must be modified. Each database type must have a database provider for data access to the Application Block and contain a compatible mode.
The Data Access Application Block backend storage option is applicable to the scenarios where the Smart Client and each application domain have their own cached server applications and the database to be accessed.
Each cachemanager running in a single application domain must use different database partitions. A partition is defined as a combination of application names and cache instance names. Databases can run on the same server or different servers as applications that use the cache. The number of cached applications supported by the database only depends on the Storage Limit of the database.

Server scenario considerations
A single cache manager cannot be shared across application domains. The server application deployed on multiple computers has a unique copy of the memory cache on each computer. This is also true for multiple processes running on the same computer, includes enterprise service components that run in their own processes and use cached application blocks. Each process has its own memory cache copy.
Different applications cannot access backend storage instances and partitions of application blocks using the same data. Using the cache application block configuration to run different applications using the same database instance and partition will lead to unpredictable results, and this is not recommended.
When the same application runs in multiple processes (for example, if the application is deployed on multiple computers in the Web farm), you can use one of the following three methods to configure the cache application block:

• All application instances use the same database instance, but each application instance uses different database partitions. For more information, see scenario 1.
• All application instances use the same database instance and database partition, and all cache managers can read and write the cache. For more information, see scenario 2.
• All application instances use the same database instance and database partition, but only one cache manager can write cache. All cache managers can read data from the cache. For more information, see scenario 3.

Scenario 1: partition Cache
Scenario 1: All application instances use the same database instance, but each application instance uses different database partitions. In this scenario, the operations of each cache manager are independent. Although they share the same backend storage database instances, each cache manager persistently caches data to different partitions. Each application instance has only one valid cache. When an application restarts, each cache manager loads its data from its own partition in the backend storage.
If the application pre-loads the cache, each deployed application instance obtains data from the original data source. Preload data uses the backend storage space of each deployed application instance. This means that deploying the same application to multiple processes is not more efficient than deploying different applications when the cache is used.
Deploy the same application to multiple servers, and each configuration application block of the server is configured with the same (for example, all application blocks use the same Expiration Policy ), it is not guaranteed that the data in each backend storage partition is the same. The data in the backend storage partition copies the memory cache data configured to use the cache manager of the backend storage partition. The content in the memory cache changes with the use of specific instances of the cache application. Because the application requires to be routed to different servers, the memory cache on each server may be different, therefore, the content in the backend storage partition may be different. This means that even if all applications are shut down and restarted at the same time, there is no guarantee that the data in the memory cache is the same after each cache is initialized with the data in the backend storage.
Scenario 2: Shared partitions
Scenario 2: All application instances use the same database instance and the same database partition, and all cache managers read and write the cache. In this scenario, each application instance operates on a memory cache that is unique to each other. When an application creates a cache manager, the cache manager puts the data stored in the backend into the memory cache, which means that if the application creates a cache manager when it starts, if all application instances are started at the same time, the same data will be loaded for each memory cache. Because the application uses the same partition, no additional storage is required for each application instance in the backend storage.
The time when the cache manager is created is the only time that the data is loaded from the backend storage to the memory cache. After that, the content in the memory cache will be determined by the cached application instance. Application Instances can use different caching methods because they need to be routed to different servers. Different Application Instances can have different memory caches.
As the application adds and deletes entries, the content in the memory cache changes, and the content in the memory cache changes when the cache manager removes or removes expired entries. As the memory cache changes, Cache Management updates backend storage to reflect these changes. The cache manager is not notified when the memory of the backend storage changes. Therefore, when an application instance changes the content of the backend storage, other applications will have memory caches that do not match the backend storage data. This means that after the application restarts, the memory cache may have different content than before the application restarts.
When an entry expires, the application can be notified by the submission event provided by the cache manager. The application can use this notification to refresh the cached data from the source data source. When an application adds a refreshed cache entry to the cache, the cache manager also uses the data to update the backend storage. If an application is deployed on multiple computers, each application instance receives an event and initializes a request to the original data source for the same entry. These requests have a significant negative impact on the performance of the application and the original data source. Therefore, it is not recommended to use notifications to monitor expiration for the purpose of refreshing expired cache entries.
Scenario 3: single write
Scenario 3: All applications use the same database instance and database partition, while only one cache manager can write the cache, and all the cache managers can read the cache. In this scenario, only one application instance writes to the cache, and all other utility instances can only read from the cache. The application instance that can write the cache is a host, and the host's memory cache has the same data as the back-end storage. The memory cache in each application instance is filled with data from the backend storage when the cache manager is created. Only one data snapshot can be obtained from the application instance read in the cache. Because the application instance does not have the ability to refresh their cache, their cache will expire and shrink when the entries expire.