For EJB 2.x container managed persistence (CMP) entity
beans, use the partial operation as a persistence option to specify
how you want to update the persistent attributes of the CMP bean to
the database.
There are two values you can select for partial operation: NONE or UPDATE_ONLY.
The default setting for partial operation is NONE, where all the persistent
attributes of the CMP bean to the database are stored to the database,
even though only a subset of the persistent attributes fields might
have changed. The UPDATE_ONLY option for the partial operation, limits
update to the database to only persistent attributes of the CMP bean
that have been modified. The setter methods on the bean determine
if the corresponding CMP attributes has been modified. The modification
is not based on the actual value being changed. In other words, if
the setter method is invoked but the old and new values remain the
same, the CMP attribute is considered dirty.
You can specify the partial operation as a persistent option at
the bean level in the access intent policy configured for the bean.
For more details on how to specify the partial operations, see Adding bean-level
access intent for entity beans 2.x.
Functional Benefits
The partial update (selecting the UPDATE_ONLY value for the partial
operation) option is designed to have the following functional benefits:
- When all the columns are always updated, any update triggers on
the table mapped to the CMP bean are always fired. This can leave
the database in an inconsistent state. Also any trigger logic depending
on the number of times a particular column is updated or the time
a particular column is updated does not work correctly with full update.
Use of partial update overcomes these limitations and enables the
use of update triggers with CMP beans.
- Partial update supports using nullable columns as predicates for
optimistic concurrency.
Performance benefits
The partial update option is designed to have the following performance
benefits:
- Reduce query execution time since only a subset of the columns
is in the query. Improvements can be greater for tables with many
columns and indexes. For example, if the table has many indexes, only
the indexes affected by the updated columns needs to be updated by
the back-end database.
- Reduce network I/O since less data to be transmitted.
- Save processing time on unchanged CMP fields that have expensive
converters, composers, or other complex transformations. In other
words, for CMP fields that are non-trivially mapped to back-end database,
such as mapping to converters, composers, or other complex transformations,
execution time for this processing is saved when that CMP field remains
unchanged.
- Eliminate unnecessary firing of update triggers. For example,
if a CMP field remains unchanged, any trigger depending on the corresponding
column is not fired.
Adverse affects to performance
Although partial update is designed to improve performance, it
can adversely affect performance too. When considering to use partial
update, also consider the following factors:
- For a CMP bean with n CMP attributes that can be modified,
there are 2n-1 different partial update queries
possible. If you use partial update for a bean and your application
is modifying several different combinations of attributes on that
bean in a short time, this could generate up to 2n-1 different
partial queries and this quickly fills-up the prepared statement cache.
As a result, prepared statements handles are discarded from the cache
and some statements are prepared again and again. This reduces performance.
- When selecting both the UPDATE_ONLY value
for the partial operation and the Batch value as persistent
options for the same bean, the batch update performance for update
queries might be affected. This is because each partial query is different
and only the same partial queries are grouped for batch update. By
default, the batch update of update queries is disabled. For details
on how you can override the precedence of partial update over batch
update, refer to the Restrictions section.
Although the Java™ Virtual Machine (JVM) property, -Dcom.ibm.ws.pm.grouppartialupdate=true,
set in the server.xml file can be used to group the similar partial
update queries into a batch update, this would only help if the partial
queries in a transaction are the same shape most of the time. You
need to determine which would provide the best performance for its
usage: batch update only, partial update only, or using both (when grouppartialupdate flag
is set to true).
- Since partial update queries are dynamically assembled during
runtime based on which CMP fields have been modified, there is a cost
in execution time that is proportional to the number of CMP fields
changed.
Restrictions
- Batch update performance could be lost when partial update is
used. The default setting for the batch updates of update queries
is disabled for all CMP beans when partial
update is enabled. In other words, partial update takes precedence
over batch update. However, the batch update behavior for delete and
insert queries is not affected by partial update, and remains unchanged.
To override the precedence of partial update over batch update:
- Open the server.xml file.
- Change the value of -Dcom.ibm.ws.pm.grouppartialupdate property
to true. When this property is set to true
and partial update is selected, the batch update of update queries
group similar partial queries.
- Partial update is not supported for SQLJ or CMP/A.