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 the topic Adding bean-level access intent for entity beans 2.x.
Functional Benefits
Using partial update (selecting the UPDATE_ONLY value for the partial operation)
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 enable the use of update triggers with CMP beans.
- Supports using nullable columns as predicates for optimistic concurrency.
Performance benefits
The use of partial update 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 backend 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 backend database, such as, have 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 check box as persistent options for
the same bean, the batch update performance for update queries might be impacted.
This is due to each partial query being different and only the same partial
queries is grouped for batch update. By default, the batch update of update
queries are 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.