CacheLookup Typa: None, NotInTTS, Found, FoundAndEmpty and EntireTable/ Loading pricedisctable is very slow

Thu, 04 Feb 2010 02:31:00 GMT

Record Caching

Microsoft Dynamics AX database record caching is a performance-enhancing feature that helps avoid database access when it's not strictly necessary. Retrieving database records from memory instead of the database significantly speeds up data access. Caching can reduce the performance penalty for repetitively accessing the same database records.

For an in-depth look at caching and its affect on performance, see Greef, Pontoppidan, et al. 2006. Inside Microsoft Dynamics AX 4.0. 427-461. Redmond: Microsoft Press.

Types of Caching

Caching is transparent to the application; however, it's important to know how caching works to optimize its performance in Microsoft Dynamics AX. Following are the types of caching:

Single-record
Set-based

Single-record caching has the following characteristics:

Defined at design time
Moves records to the cache based on the table's CacheLookup property and the type of SELECT statement that is used to retrieve the record

For more information about record caching, see Single-Record Caching.

Set-based caching has the following characteristics:

Defined either at design time or in X++ code
Moves sets of records to the cache
Implemented either through the table's CacheLookup property or in code by using the RecordViewCache class

1, Single-Record Caching

Record caching is enabled for a table when all the following statements are true:

The CacheLookup property on the table is enabled by setting it to one of the following values:
- notInTTS
- Found
- FoundAndEmpty
The table's PrimaryIndex property is set to a unique index that exists on the table. The RecId index does not qualify as a caching index unless you set the table's PrimaryIndex property to this index.
The record buffer disableCache method has not been called with a parameter of true.

The fields in the table's unique index make up the caching key. A record is placed in the cache when the following criteria are met:

The table is cached by setting the CacheLookup property to notInTTS, Found, or FoundAndEmpty.
The SELECT statement that selects the records uses an equal operator (==) on the caching key. The fields in the WHERE clause of the SELECT statement match the fields in the index referenced by the table's PrimaryIndex property.

The table's CacheLookup property defines how and when records are cached as shown in the following table.

CacheLookup Property Value	Result
None	No data is cached or retrieved from the cache for this table. This property value should be used for tables that are heavily updated or where it's unacceptable to read outdated data.
NotInTTS	All successful caching key selects are cached. When in a transaction (after ttsBegin), no caches made outside the transaction are used. When inside a transaction, the record is read once from database and subsequently from cache. The record is select-locked when read in a transaction, which ensures that the record cached is not updated while the transaction is active. A typical example of the `NotInTTS` property is the CustTable in the Microsoft Dynamics AX standard application. It's acceptable to read outdated data from the cache outside a transaction, but when data is used for validation or creating references, it is ensured that the data is real-time.
Found	All successful caching key selects are cached. All caching key selects are returned from the cache if the record exists there. A `selectforUpdate` in a transaction forces reading from the database and replaces the record in the cache. This is typically used for static (lookup) tables, such as Unit, where the record usually exists.
FoundAndEmpty	All selects on caching keys are cached, including selects that are not returning data. All caching key selects are returned from caching if the record exists there, or the record is marked as nonexistent in the cache. A `selectforUpdate` in a transaction forces reading from the database and replaces the record in the cache. An example of `FoundAndEmpty` record caching is in the Discount table in the Microsoft Dynamics AX standard application. By default, the Discount table has no records. By using a FoundAndEmpty cache on this table, the keys that are queried for but not found are stored in the cache. Subsequent queries for these same non-existent records can be answered from the cache without a round trip to the database.
EntireTable	Creates a set-based cache on the server. The entire table is cached as soon as at least one record is selected from the table.

The Found and FoundAndEmpty caches cross transaction boundaries. The NotInTTS cache is newly created inside a transaction. The following code example is from Greef, Pontoppidan, et al. 2006. Inside Microsoft Dynamics AX 4.0. 445. Redmond: Microsoft Press. This example, modified for the purposes of this topic, demonstrates how records are retrieved from the cache when the table's CacheLookup property is set to NotInTTS, and the PrimaryIndex property is set to a unique index on the AccountNum field.

Copy Code

static void NotInTTSCache(Args _args)
{
CustTable custTable;
;
// The query looks for records in the cache.
// If records don't exist, the query accesses the database.
select custTable
where custTable.AccountNum == '4000';
// The transaction starts.
ttsbegin;
// The cache is not used. The query accesses the database
// and records are placed in the cache.
select custTable
where custTable.AccountNum == '4000';
// The query uses the database because
// the forupdate keyword is used.
select forupdate custTable
where custTable.AccountNum == '4000';
// The query uses the cache and not the database.
select custTable
where custTable.AccountNum == '4000';
// The query uses the cache because
// the forupdate keyword was used previously.
select forupdate custTable
where custTable.AccountNum == '4000';
// The transaction is committed.
ttscommit;
// The query will use the cache.
select custTable
where custTable.AccountNum == '4000';
}

Reproduced by permission from Greef, Pontoppidan, et al, Inside Microsoft Dynamics AX 4.0 (Redmond, WA: Microsoft Press, 2006), 445.

If the table CacheLookup property was set to Found or FoundAndEmpty, the first select statement inside the transaction (after the TTSBegin statement) would retrieve the record from the cache.

Cache Location

Caches are used on both the client and the server. The Microsoft Dynamics AX runtime manages the cache by removing old records when new records are added to the cache.

Client Cache

A client-side cache can be used only by the client. The client cache is used when a select is executed from the client tier. If no record is found in the client cache, the client then searches the server cache for the record. If the record isn't located in the server cache, it's retrieved from the database. The maximum number of records maintained in a client cache is 100 records per table for a given company.

Server Cache

A server-side cache can be used by any connection to the server. The server cache is used when a select is executed on the server tier. If no record is found in the cache, it's retrieved from the database. The maximum number of records maintained in a server cache is 2,000 records per table for a given company.

2, Set-Based Caching

In Microsoft Dynamics AX, groups of records can be cached all at once with set-based caching. Set-based caching can be implemented in two ways:

At design time, by setting the table's CacheLookup property to EntireTable.
In code, by using the RecordViewCache class.

EntireTable Cache

When you set a table's CacheLookup property to EntireTable, all the records in the table are placed in the cache after the first select. This type of caching follows the rules of single record caching in which the SELECT statement WHERE clause fields must match those of the unique index defined in the table's PrimaryIndex property.

The EntireTable cache is located on the server and is shared by all connections to the Application Object Server (AOS). If a select is made on the client tier to a table that is EntireTable cached, it first looks in its own cache and then searches the server-side EntireTable cache. An EntireTable cache is created for each table for a given company. If you have two selects on the same table for different companies the entire table is cached twice.

Joins that include an EntireTable cached table are only performed against the cached copy when all tables participating in the join are EntireTable cached. Otherwise a database join is performed.

Note
Avoid using EntireTable caches for large tables because once the cache size reaches 128 KB the cache is moved from memory to disk. A disk search is much slower than an in-memory search.

For more information about EntireTable caching, see Inside Microsoft Dynamics AX 4.0, Chapter 17.

Flushing the Cache

An EntireTable cache is flushed whenever an insert, update, or delete is made to the table. At the same time, the AOS notifies other AOSs that their caches of the same table must be flushed. After the cache is flushed, a subsequent select on the table causes the entire table to be cached again. Therefore, avoid caching any table that's frequently updated. Regardless of when updates are made, EntireTable caches are flushed every 24 hours by the AOS.

RecordViewCache Cache

Set-based caching is implemented in code by using the RecordViewCache class. You must first create a record buffer using the nofetch statement and then pass the record buffer to the RecordViewCache class when it's instantiated.

The cache is created on the server and is only accessible by the process that creates the cache object. Once the cache is instantiated, all select statements are issued against the cache, as shown in the following code (from Inside Dynamics AX 4.0, Chapter 17, page 450).

Copy Code

static void RecordViewCache(Args _args)
{
CustTrans       custTrans;
RecordViewCache recordViewCache;
;
// Define records to cache.
select nofetch custTrans
where custTrans.AccountNum == '4000';
// Cache the records.
recordViewCache = new RecordViewCache(custTrans);
// Use cache.
select firstonly custTrans
where custTrans.AccountNum == '4000' &&
custTrans.CurrencyCode == 'USD';
}

Due to concurrency issues, the forUpdate keyword on the instantiating X++ SELECT statement should only be used when all of the records in the result set will be updated. Otherwise it's a better strategy to use selectforUpdate only for the records that are to be updated.

The RecordViewCache class is used in a select when the select is from a table that's cached, the select statement doesn't participate in a join and the select WHERE clause matches the WHERE clause with which the RecordViewCache was instantiated.

The cache created by the RecordViewCache class stores records in a linked list. Therefore Microsoft Dynamics AX searches the cache sequentially for records that match the search criteria. If the SELECT statement contains an ORDER BY clause, a temporary index is placed on the cache and the runtime uses the index when searching records.

The EntireTable Cache

In addition to the three caching methods described so far, a fourth caching option can be set on a table. This option is the EntireTable, which enables a set-based cache. The option causes the AOS to mirror the table in the database by selecting all records in the table and inserting them into a temporary table when any record from the table is selected for the first time. The first process to read from the table could therefore experience a longer response time because the application runtime reads all records from the database. Subsequent select queries then read from the entire-table cache instead of from the database.

A temporary table is usually local to the process that uses it, but the entire-table cache is shared among all processes that access the same AOS. Each company (as defined by the DataAreaId field) has an entire-table cache, so two processes requesting records from the same table from different companies use different caches, and both could experience a longer response time to instantiate the entire-table cache.

The entire-table cache is a server-side cache only. When requesting records from the client tier on a table that is entire-table cached, the table behaves as a Found cached table. If a request for a record is made on the client tier that qualifies for searching the record cache, the client first searches the local Found cache. If the record is not found, the client calls the AOS to search the entire-table cache. When the application runtime returns the record to the client tier, it inserts the record into the client-side Found cache.

The entire-table cache is not used when executing a select statement by which an entire-table-cached table is joined to a table that is not entire-table cached. In this situation, the entire select statement is parsed to the database. However, when select statements are made that access only the single entire-table cached table, or when joining other entire-table cached tables, the entire-table cache is used.

The Dynamics AX application runtime flushes the entire-table cache when records are inserted, updated, or deleted in the table. The next process, which selects records from the table, suffers a degradation in performance because it must re-read the entire table into cache. In addition to flushing its own cache, the AOS that executes the insert, update, or delete also informs other AOSs in the same installation that they must flush their caches on the same table. This prevents old and invalid data from being cached for too long in the entire Dynamics AX application environment. In addition to this flushing mechanism, the AOS flushes all the entire-table caches every 24 hours.

Because of the flushing that results when modifying records in a table that has been entire-table cached, you should avoid setting up entire-table caches on frequently updated tables. Rereading all records into the cache results in a performance loss, which could outweigh the performance gain achieved by caching records on the server tier and avoiding round trips to the database tier. The entire-table cache setting on a specific table can therefore be overwritten at run time when you configure the Dynamics AX application.

Even if the records in a table are fairly static, you might achieve better performance by not using the entire-table cache if the number of records in the table is large. Because the entire-table cache uses temporary tables, it changes from an in-memory structure to a file-based structure when the table uses more than 128 kilobytes (KB) of memory. This results in performance degradation during record searches. The database search engines have also evolved over time and are faster than the ones implemented in the Dynamics AX application runtime. It might be faster to let the database search for the records than to set up and use an entire-table cache, even though a database search involves round trips to the database tier.

For PriceDiscTable included Trade Agreement information. When you create a Sales/Purchase line, it become very slow when your pricedisctable has 30000 records because the table's cache (cache lookup) type is entiretable. It is possible to change cache type to Found.

何克�?/a> 2010-02-04 10:31 发表评论

Wed, 03 Feb 2010 10:53:00 GMT

RunOn�Q�顾名思义�Q�就是指Object在那一层上面运行，客户端，�q�是服务器端�Q�当�Ӟ��前提是要在三层结构下面。Axapta当中与RunOn有关的，大概在以下这几个地方�Q?/p>

相关的Object�Q�如Form, Report, Class�{�，Class当中的静态方法，以及MenuItem�?/p>

Form和Report是不能设�|�RunOn属性的�Q�Form只能是运行在客户端，而Report则是由MenuItem所军_��的，因�ؓ它的RunOn属性其实是被设�?Always)Called from的。当�Ӟ��假如Report不用MenuItem指定�Ȁ�zȝ��话，如直接在AOT当中用右键打开(Open)�Q�那��p��定是在客��L��生成了�?/p>

那么剩下可以讨论的就是Class的RunOn属性，和Class当中的静态方法了�?/p>

静态方法，由它本��n的modifier所军_��。不写的情况下，默认为client server�Q�可昑ּ�声明�Q�一般情况下不用�Q�，也就是等于Called from�Q�在哪里被调用就在哪里运行�?/p>

Class本��n的RunOn属性是��h��最高优先��的，只有当设�|��ؓCalled from的时候，才会取决于MenuItem中的RunOn属性。还有一�U�情况就是，很多Class的main�Ҏ��也指定了modifier�Q�这个时候main�Ҏ��的modifier比MenuItem更有优先权来军_��Class�q�行的位�|��?/p>

也就是说Class的RunOn属�?优先�?main�Ҏ��的modifier 优先�?MenuItem的RunOn属性�?/p>

那么我们再来讨论�q�个RunOn属性的作用�?/p>

我们知道�Q�在Axapta三层�l�构体系当中�Q�不同层之间的调用，无论是方法，�q�是数据的交换，都会造成�q�行效率的降低。所以我们必��要��可能减��不同层之间的调用。譬如说�Q�某个Class具体的作用是�q�行数据�q�算�Q�那么这个时候我们把它放在Client端运行是非常不合理的。因��U�情况下它需要和database�q�行大量的数据交换（中间需要通过AOS�Q�，所以我们就需要强制性的把它指定�q�行在AOS上，�q�样也可以减��了�|�内部的带宽消耗，更可以充分利用三层结构的优点�Q�降低了客户端机器的负蝲�?/p>

然后�q�是有一个Best Practice原则�Q�就是尽量把RunOn讄��在MenuItem�Q�而不要指定在Class本��n的属性上面（��量默认为Called from�Q�。这样做的好处在于，可以灉|��q�用�Q�因为某一个Class可以在不同的情况下，被指定运行在不同层上。开发�h员只需要更改和使用不同的MenuItem�Q�就可以辑ֈ��q�种效果。这也是Axapta里面所谓的API原则�Q�尽量都通过MenuItem��L��z�d��指定Object的运行状态�?/p>

本文来自CSDN博客�Q��{载请标明出处�Q�http://blog.csdn.net/junevoful/archive/2006/01/06/572496.aspx

何克�?/a> 2010-02-03 18:53 发表评论

日韩欧美视频一区,在线一二三区,亚洲欧洲在线看

CacheLookup Typa: None, NotInTTS, Found, FoundAndEmpty and EntireTable/ Loading pricedisctable is very slow

Client Cache

Server Cache

Flushing the Cache