In Enterprise edition, you can specify a table view as memory-resident setting MemoryResident = True. In Express edition you can make a C1WebExpressTable memory-resident setting MemoryResident = True. In any data set, you can make one or more table views memory-resident while storing the rest in the global cache or in the session cache. Memory-resident table views are automatically excluded from global and session cache operations.
A memory-resident table view is fetched from the database only once, when it is first requested, and then it will be just reused on every user request, for any user, at no performance cost.
This is, of course, a powerful technique to optimize performance, but it can only be used for read-only tables. A memory-resident table view must be read-only (TableView.ReadOnly = True) and it can be based only on read-only tables (Table.ReadOnly = True).
And another restriction applies to memory-resident table views: you can't specify different filter conditions for them calling C1DataSet.Fill. Memory-resident table views are always in memory, they are skipped when data is fetched in C1DataSet.Fill, except when it is the first fetch of the application. Therefore, you can't change their filter conditions, they need to be constant. The filter condition will take effect only once for the application, in the first Fill.
More precisely, a memory-resident table can be fetched more than once, due to concurrency issues. This occurs when a user requests the table view while it is being used by another user request. In this case, if the object pool is not full, a new worker object is created (see Object Pooling), added to the pool, and the memory-resident table view is fetched to that worker object. So, a memory-resident table views belongs to a worker object, and maximum number of times it is fetched is the maximum worker object count in the pool, which is specified by the PoolSize property.
|
