web123456

04-01 Cached Data Store

Cached Data Store(cacheData storage）

XPO provides functionality for a cache at the data store level. The cache stores queries and their results as they are being executed on a data store. Whenever a query, which has been executed before, passes the cache, the result from that query is returned back immediately without a roundtrip to a data store. This significantly improves performance in general and ensures that as little data as possible is transferred over the wire in distributed applications.
XPO provides functionality for data storage-level cache. Caches queries and their results executed on the data store. Whenever a previously executed query passes cache, the result of the query is returned immediately without round trips to the data store. This has improved significantly overallperformance, and ensure as little data as possible is transmitted over the network in distributed applications.

To enable data store caching, four classes specifying the Root and its Nodes - DataCacheRoot, MSSql2005SqlDependencyCacheRoot, DataCacheNode and DataCacheNodeLocal - must be combined. The minimum setup of the cache requires one Root (DataCacheRoot or MSSql2005SqlDependencyCacheRoot) and one Node (DataCacheNode or DataCacheNodeLocal). It is possible to build cache hierarchies out of a single Root and any number of Nodes, which can be linked to the Root or another Node. This makes sense in client/server setups, when certain parts of an application need to use different settings for their data access, such as current data.
To enable data storage caching, four classes that specify Root and its nodes must be merged - DataCacheRoot, MSSql2005SqlDependencyCacheRoot, DataCacheNode, and DataCacheNodeLocal. The minimum cache setting requires a Root (DataCacheRoot or MSSql2005SqlDependencyCacheRoot) and aNode(DataCacheNode or DataCacheNodeLocal). A cache hierarchy can be built from a single Root and any number of Nodes, and these nodes can be linked to a Root or another Node. This makes sense in client/server settings, when certain parts of the application need to access data using different settings, such as the current data.

The Nodes actually cache data, while the Root stores the information about table updates and synchronizes it with Nodes. To keep the table update information and cached data in sync, the Root and Nodes communicate with each other using the ICacheToCacheCommunicationCore channel. Every time a Node contacts its parent (a Root or another Node), table update information is passed in the direction from Root to Node. These regular contacts between a Node and its parent are required to keep the table information current. The latency for these contacts can be specified using the field. This field defines the maximum time that is allowed to pass before a contact to the parent becomes mandatory. So, if a Node receives a query, it first finds a cached result set for this query, and if more time than specified by has passed since its last parent contact, it will perform a quick request to its parent to synchronize table update information.
Node actually caches data, while Root stores information about table updates and synchronizes it with Nodes. To keep table update information and cached data synchronized, Root and Nodes communicate with each other using the ICacheToCache CommunicationCore channel. Each time a Node contacts its parent node (Root or another Node), table update information is passed from Root to Node. These conventional connections between Node and its parent node are necessary to keep table information up to date. The delays for these contacts can be specified using the DataCacheNode.MaxCacheLatency field. This field defines the maximum time allowed to pass before contacting the parent node becomes mandatory. Therefore, if a node receives a query, it first finds a cached result set for the query, and if the time specified by DataCacheNode. MaxCacheLatency has passed since its last parent contact, it will perform a quick request to its parent to synchronize the table update information.

Note
Data store caching relies on the idea that the cache structure knows about changes being made to data. So, even in a multi-user setup, you
should make sure that all queries and updates are performed in a way
that allows them to be recognized by the cache structure. To
accomplish this, all client requests for data have to be routed
through the client-side Nodes (DataCacheNode instances) and
server-side Root (or server-side Root-Node chains). If, for any
reason, there are changes in the database that have been made without
going through the cache structure, you can use the following utility
methods.
Datastore caches rely on the idea of ​​the cache structure knowing the changes made to the data. So, even in a multi-user setup, you should make sure that all queries and updates are performed in a way that allows the cache structure to recognize them. To achieve this, all client requests for data must be routed through client nodes (DataCacheNode instances) and server-side Root (or server-side Root-Node chain). If for any reason a change that has not been made through the cache structure in the database, you can use the following utility method.

  • The method of a Root or Node (for the MSSql2005SqlDependencyCacheRoot, use its
    ) - To inform the
    cache about specific table changes.    DataCacheBase for Root or Node.
    NotifyDirtyTables method (for MSSql2005SqlDependencyCacheRoot, use it) - Notify cache specific table changes

  • A Node’s method - To synchronize the cache completely. Node's DataCacheNode.CatchUp method - Fully synchronous cache.

Direct SQL queries and stored procedure calls are not cached. To properly adjust a cache after calls, use any of the methods listed
above. If you are using a Microsoft SQL Server (version 2005 and
later) database as a backend for a data store, you can enable the
cache hierarchy to be automatically notified about table updates using
SqlDependency (see below).
Direct SQL queries and stored procedure calls are not cached. To properly adjust the cache after the call, use any of the methods listed above. If you are using a Microsoft SQLServer (version 2005 and later) database as the backend for your data storage, you can use SqlDependency to automatically notify cache hierarchy table updates (see below).

Using SqlDependency(Use SqlDependency)

SqlDependency is a Microsoft SQL Server feature (found in version 2005 and later) that allows the database server to notify a client about changes that occur in the database. You can enable the cache hierarchy to exploit this feature to be automatically notified about any changes made to a cached database (even if they are made outside the cache hierarchy). To accomplish this, do one of the following.
SqlDependency is a feature of Microsoft SQL Server (available in version 2005 and later) that allows the database server to notify changes in the client database. You can enable the cache hierarchy to take advantage of this feature to automatically notify any changes made to the cache database (even if they are made outside the cache hierarchy). To achieve this, do one of the following.

Use the MSSql2005SqlDependencyCacheRoot as the Root element in your cache hierarchy. To create the Root element, call the overloaded methods.
Use MSSql2005SqlDependencyCacheRoot as the root element in the cache hierarchy. To create the root element, call the MSSql2005SqlDependencyCacheRootCreateSqlDependencyCacheRoot overload method.
Create a cached data store provider using the MSSql2005SqlDependencyCacheRoot.CreateProviderFromString_CacheRoot or MSSql2005SqlDependencyCacheRoot.CreateProviderFromString_WithCache method. These methods automatically create a MSSql2005SqlDependencyCacheRoot instance and associate it with this provider.
Create a cache data storage provider using the MSSql2005SqlDependencyCacheRootCreateProviderFromString_CacheRoot or MSSql2005SqlDependencyCacheRootCreateProviderFromString_WithCache method. These methods automatically create an MSSql2005SqlDependencyCacheRoot instance and associate it with this provider.
Create a cached data store provider based on connection strings returned by the MSSqlConnectionProvider.GetConnectionString2005CacheRoot or MSSqlConnectionProvider.GetConnectionString2005WithCache method. When a cached data store provider is created, a MSSql2005SqlDependencyCacheRoot instance will be automatically created and associated with this provider.
Create a cache data storage provider based on the connection string returned by the MSSqlConnectionProviderGetConnectionString2005CacheRoot or MSSqlConnectionProviderGetConnectionString2005WithCache method. When creating a cached data storage provider, an MSSql2005SqlDependencyCacheRoot instance is automatically created and associated with this provider.

C#
string connectionString = "data source=.;initial catalog=DBName;integrated security=sspi";
IDisposable[] disposeOnDisconnect;
IDataStore node = MSSql2005SqlDependencyCacheRoot.CreateProviderFromString_WithCache(
    connectionString, AutoCreateOption.DatabaseAndSchema, out disposeOnDisconnect);
XPDictionary dict = new ReflectionDictionary();
dict.GetDataStoreSchema(typeof(Customer).Assembly);
XpoDefault.DataLayer = new ThreadSafeDataLayer(dict, node);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

The SqlDependency feature is resource-demanding - every time a change happens in a database table that is being monitored, every client subscribed to SqlDependency must be notified. It is thus recommended to have only one MSSql2005SqlDependencyCacheRoot associated with a database, publishing change notifications to all other cache hierarchy Nodes.
The SqlDependency feature is very resource-related - every time the monitored database table changes, you must notify every client that subscribes to SqlDependency. Therefore, it is recommended that only one MSSql2005SqlDependencyCacheRoot is associated with the database, publishing the change notification to all other cache hierarchy nodes.

To learn about prerequisites for the SqlDependency feature use, refer to the Special Considerations When Using Query Notifications MSDN article.
To learn about the prerequisites for using the SqlDependency feature, see Using query notificationsMSDNSpecial precautions when it comes to this article.

Cache Configuration Settings(Cache configuration settings)

With cache configuration settings, you can easily configure the caching scope for Nodes by designating tables to be cached. Since there is no need to cache tables that are frequently changed, you can exclude them from the caching scope using configuration settings. To specify the settings, use the Root’s method. For the MSSql2005SqlDependencyCacheRoot, use the corresponding overloaded method.
Using the cache configuration settings, you can easily configure the cache range of Nodes by specifying the tables to be cached. Since there is no need to cache frequently changed tables, you can use configuration settings to exclude them from the cache scope. To specify settings, use Root's DataCacheBase.configuration method. For MSSql2005SqlDependencyCacheRoot, use the corresponding MSSql2005SqlDependencyCacheRootCreateSqlDependencyCacheRoot overload method.

Connecting to Cached Data Stores in Distributed Applications(Connect to cached data store in distributed applications)

You can publish cached data stores (ICachedDataStore implementers) in your distributed applications. When your client application connects to a cached data store using either the http://host:port/ or ://host:port/servicename connection string format, XPO automatically creates a Node (a DataCacheNode object) on the client. You can then create any number of Nodes and Node chains on the client, and link them to this Node to create a cache hierarchy. If you exploit the SqlDependency feature in your cached data store, the resulting distributed application setup will benefit from change notifications on the database server without great resource requirements.
You can publish cached data stores (ICachedDataStore Implementer) in distributed applications. When your client application uses http://host:port/ or net.tcp://host:port/servicename connection string format is connected to the cached data store, XPO will automatically create a node (DataCacheNode object) on the client. You can then create as many nodes and node chains on the client and link them to this node to create a cache hierarchy. If you take advantage of the SqlDependency feature in the cached data store, the generated distributed application settings will benefit from change notifications on the database server without the need for a large amount of resources.

On the service side, we recommend creating the DataCacheRoot only. Normally, a service that utilizes the CachedDataStoreService class should be published on the same machine or in the same local network with the database server. In this configuration, traffic between the service and the database should not significantly affect performance, and usually it is not necessary to cache these queries. However, some applications may perform many heavy queries with aggregations or grouping, and these operations may take significant time on the database side. We provide a DataCacheNode descendant for this situation - DataCacheNodeLocal. If your application performs many select operations with grouping and aggregations, check if using this class in the service application benefits performance.
On the server side, we recommend creating only DataCacheRoot. Generally, services using the CachedDataStoreService class should be published on the same machine as the database server or on the same local network. In this configuration, traffic between the service and the database should not significantly affect performance and these queries are usually not required to be cached. However, some applications may perform many heavy queries with aggregates or groupings, which can take a lot of time on the database side. We provide a DataCacheNode descendant for this situation - DataCacheNodeLocal. If your application performs many selection operations with grouping and aggregation, check whether using this class in a service application is beneficial to performance.

Note
You can try the functionality described here in the Connecting to a Data Store | Data Caching section of the XPO Tutorials demo
(C:\Users\Public\Documents\DevExpress Demos
24.1\Components\WinForms\Bin\).You can try the XPO tutorial demo (C:\User\Public\Documents\DevExpress Demos
24.1\Components\WinForms\bin\XpoTutorials.exe) The function described in the Connect to Data Storage | Data Cache section.