Partial column updates for container managed persistence

Previously, the WAS implementation of the Container Managed Persistence (CMP) bean method ejbStore stored all of the persistent attributes of the CMP bean to the database, even if only a subset of persistent attribute fields were changed. This needless performance degradation is eliminated in this release of WAS ND.

Entity beans are not supported in EJB 3.0 modules.

For EJBs 2.x CMP entity beans, we can use the partial update feature to specify how you want to update the persistent attributes of the CMP bean to the database. This feature is provided as a bean level persistence option, called PartialOperation, in the access intent policy configured for the bean. PartialOperation has two possible values:

NONE

Partial update is turned off. All of the persistent attributes of the CMP bean are stored to the database. This is the default value.

UPDATE_ONLY

Specifies that updates to the database occur only for the persistent attributes of the CMP bean that are changed.

For information on how to set partial update, see Set partial update for container-managed persistent beans.

Performance

Performing partial updates increases performance in several ways:

• by reducing query execution time, since only a subset of the columns are in the query. Improvement is higher for tables with many columns and indexes.

  When the table has many indexes only the indexes affected by the updated columns need to be updated by the backend database.

• by reducing network input and output since there is less data to be transmitted.

• by saving any processing time for non-trivially mapped columns. For example, if a column uses converters, composers, and transformations to partially inject the input record.

• by eliminating unnecessary firing of update triggers. If a CMP bean field is not changed, any trigger depending only on the corresponding column is not fired.

Although partial update improves performancel, it can adversely affect performance as follows:

• If we enable partial update for a bean that the application modifies several different combinations of columns during the same time span, the prepared statement cache maximum for the connection is reached very quickly. As a result, statement handles are evicted from the cache based on least recent usage. This results in statements being prepared repeatedly, decreasing performance for all CMP functions, not just limited to the ejbStore method.

• Partial update query templates cached in the function set increase memory use. The increase is linear relative to the number of fields in the CMP bean for which the partial update access intent option is turned on.

• The PartialOperation persistent option, when used in combination with the Batch Update persistent option, affects the performance of the batch update because each partial query is different. There is an execution time cost incurred for generating a partial update query string dynamically. Since query fragments are stored for each column, the execution cost to assemble the query fragments is linear, based on the number of CMP bean fields dirtied.

• There are condition checks for each CMP field, for example, to inspect the dirty flags and to execute the preparedStatement setXXX method calls.

Considerations for using partial update

The performance gains you hope to achieve should be weighed against the possible instances where degradation can occur. Use the following guidelines to help you make the decision.

• Partial update might not benefit an application that only involves a small table with a few columns and simple data types and no update triggers.

  The cost to assemble the partial query dynamically outweighs the performance gain.

• Partial update is a benefit if there is a complex data type not updated often. An example of a complex data type is an employee bean with a “photo” CMP attribute mapped to a BLOB OR VARGRAPHIC, or similar complex backend type, that is typically stored in a different location in the database manager implementation.

• Partial Update might benefit if there are several VARCHAR type columns and only a very few of them are updated.

• It is better not to use the partial operation if the application can randomly be updating different combinations of columns and the number of assignable columns (non-key) is higher than five. This generates different partial queries and fills up the prepared statement cache quickly. But, if the bean does not have too many columns, for example, four or less, and it has complex data types, we might consider turning partial update on, with the option of increasing the statement cache size to ensure an increased number of queries. For information on increasing the statement cache size, refer to Data source settings.

• Partial Update is beneficial when there are update triggers needed on a subset of columns.

• Partial Update is beneficial when the table has many columns and indexes, and only a few indexes are touched by a typical update.

Restrictions

By default, batch update of update queries is disabled for all CMP beans for which partial update is enabled. In other words, partial update takes precedence over batch update. Batch update of delete and insert queries is not affected.

Batch update performance is affected when both batch update and partial update persistence options are used on the same bean, because each partial query is different. Use the JVM property, -Dcom.ibm.ws.pm.grouppartialupdate=true, to group the similar partial update queries into a batch update. Grouping partial updates only helps when there are several partial queries with the same shape in a transaction. Otherwise, grouping partial updates has the opposite affect on performance. Because this setting is not on a bean level basis, you should be careful when turning it on. Because this affects all beans that have both partial update and batch update on, make sure that batch update of partial queries does increase performance when viewed across all the beans for which both updates are on.

To set the JVM property:

1. Open the server.xml file.
2. Change the value of -Dcom.ibm.ws.pm.grouppartialupdate=true to 
                       -Dcom.ibm.ws.pm.grouppartialupdate=false.

---

 

Related tasks

Set partial update for container-managed persistent beans
Use access intent policies