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 determines 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
will 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 are 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 is the batch updates of update queries is disabled for all
CMP bean 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 will group similar
partial queries.
- Partial update is not supported for SQLJ or CMP/A.