1.1

• Some applications may benefit from evicting rows to disk in order to reduce heap space. However, enabling
eviction also increases the per-row overhead that SQLFire requires to perform LRU eviction for the table. As
a general rule, table eviction is only helpful for conserving memory if the non-primary key columns in a table
are large: 100 bytes or more.
• An UPDATE will not occur on a row that has been evicted or has expired from the cache with the DESTROY
action. This limitation does not apply to tables that are configured with the OVERFLOW eviction action.
• An INSERT will succeed if an identical row (based on primary key) has been previously evicted or expired
from the cache with the DESTROY action, but the row still exists in the external data store.
Eviction in Partitioned Tables
In partitioned tables, SQLFire removes the oldest entry it can find in the bucket where the new entry operation
is being performed. SQLFire maintains LRU entry information on a bucket-by-bucket basis, because the
performance cost of maintaining information across the entire partitioned table is too great.
SQLFire chooses buckets for LRU eviction in these ways:
• For memory and entry count eviction, LRU eviction is done in the bucket where the new row is being added
until the overall size of the combined buckets in the member has dropped enough to perform the operation
without going over the limit.
• For heap eviction, each partitioned table bucket is treated as if it were a separate table, with each eviction action
only considering the LRU for the bucket, and not the partitioned table as a whole.
Eviction in a partitioned table may leave older entries for the table in other buckets in the local data store as well
as in other hosts in the distributed system. It may also leave entries in a primary copy that it evicts from a
secondary copy or vice-versa. However, SQLFire synchronizes the redundant copies when an entry with the
same primary key is inserted or updated.
Create a Table with Eviction Settings
Use eviction settings to keep your table within a specified limit, either by removing evicted data completely or
by creating an overflow table that persists the evicted data to a disk store.
Procedure
Follow these steps to configure table eviction settings. Refer to CREATE TABLE on page 476 for details about
specifying eviction settings.
1. Decide whether to evict based on:
• Entry count (useful if table row sizes are relatively uniform).
• Total bytes used.
• Percentage of JVM heap used. This uses the SQLFire resource manager. When the manager determines
that eviction is required, the manager orders the eviction controller to start evicting from all tables where
the eviction criterion is set to LRUHEAPPERCENT.
You can configure a global heap percentage for all SQLFire data stores, or configure different heap
percentages for one or more server groups. Heap Eviction Configuration Procedures on page 602 describes
how to configure the heap percentage.
Eviction continues until the resource manager calls a halt. SQLFire evicts the least recently used rows
hosted by the member for the table.
2. Decide what action to take when the limit is reached:
• Locally destroy the row.
Note: SQLFire does not propagate the DESTROY evict action to configured callback
implementations, such as DBSynchronizer. Do not configure eviction with the DESTROY action on
vFabric SQLFire User's Guide188
Caching Data with vFabric SQLFire