While the business logic tier is running, it stores view rows in a cache in memory (the Java heap). When the business logic tier needs to store many rows at once, you need to make sure it doesn't run out of memory. To do so, you can specify that when the number of rows reaches a certain size, the rows "overflow" to your database to be stored on disk. This feature is called view row spillover.
Rows with large numbers of attributes or storing large volumes of data affect memory usage more than smaller rows with less data.
When view row spillover is enabled, rows are stored in "nodes." You specify the maximum number of "active" nodes (nodes in memory) and the maximum number of rows each node can contain:
The default is 10 active nodes of a maximum 70 rows each.
When a row is full and another row is added, the node is "split" into two nodes and about half of the rows are moved to the new node. So you have two nodes of about half of the maximum number of rows in each node.
If a row is deleted from a node, the business logic tier checks if the node can be merged with another of the same type to create one node from two.
You specify the number of active nodes and rows per view object instance. You can optionally override these values in the XML file of a view object. You might want to override the values if you need a different maximum value.
Realize that the number of nodes and rows you specify is an approximate number. For example, if you specify a maximum of two nodes of ten rows each, you could possibly end up with three nodes of five rows each in memory, if the business logic tier needs it.
When there are more active nodes than is allowed in memory, spillover occurs. The business logic tier creates tables using the same schema specified in your database connection information and places rows in these tables. The following tables are created in your database:
PCOLL_CONTROL — This management table is shared by application module instances using the same JDBC connection URL. It is created immediately, before spillover occurs.
PCST_* — A new table is created for each transaction (top-level application module).
A least-recently-used algorithm determines which node is written to the database first.
Once a row is placed in the database, it does not return to memory until it is requested. A database administrator must manually clear data in the tables when it is no longer used.
Currently, you can use Oracle8i version 8.1.6 or greater databases for spillover. If you are not using these databases, your rows might be stored in memory only.
When view rows spill to disk, the entity rows they refer to in the entity object cache are released. When the view row is brought back into memory, the entity rows are also brought back.
However, if there were modifications to the entity rows, they are not released because they are part of a transaction. When the transaction has ended (through committing or aborting it), the entity rows can be released.
So, you can control how much memory is used by the entity object cache by
using view row spillover
committing transactions before there are a lot of modified entity objects
Related topics
Managing Rows in
Memory at Runtime