Performance Improvement in OC4J 9.0.4.0.1 and later
Most performance settings are discussed in Oracle Application Server 10g Performance Guide. This article discusses additional performance options that are available in OC4J 9.0.4.0.1 and later.
Eager Loading of related Entities in 1:1 Relationship
Deferring creation of database record to ejbPostCreate
Batch SQL statements
Mapping a CMP field and CMR field to the same database row
Eager Loading of related entity beans
If you have 1:1 relationship between two entity beans OC4J eagerly load the related data using a single SELECT statement using an outer join. In the previous releases OC4J would issue two SQL statements for each side of relationship. Use of this join dramatically improves the performance as a single query is used.
You can change this behavior to use an inner join by modifying the one-to-one-join attribute on the relationship field to inner, as follows:
<cmr-field-mapping name="inventory" one-to-one-join="inner">
When the 1:1 mapping is unidirectional, place the one-to-one-join attribute on the origination of the relationship. When the relationship is bi-directional, specify the one-to-one-join attribute on both sides of the relationship.
Deferring creation of database record to ejbPostCreate
In this release of OC4J the creation of database record for an entity bean creation is deferred to ejbPostCreate method. In earlier releases, data gets synchronized with an INSERT after the ejbCreate method. Then, if you add a CMR relationship in the ejbPostCreate method, an UPDATE is performed after the ejbPostCreate method. This results in two SQL statements. For performance reasons, the default is now to have database synchronization after the ejbPostCreate. If, however, you wish to have the old way of data synchronization, you can set the data-synchronization-option attribute, as follows in the orion-ejb-jar.xml for your entity bean:
data-synchronization-option="ejbCreate"
The default setting is as follows:
data-synchronization-option="ejbPostCreate"
If you have a foreign key as part of your primary key, you must set the data-synchronization-option to "ejbPostCreate" (or accept the default setting), as the foreign key has a non-null constraint. Since the primary key is set in the ejbCreate method and the foreign keys are initialized in the ejbPostCreate, all aspects of the primary key, including the foreign key, are initialized at the same time after the ejbPostCreate.
Batch UPDATE statements
OC4J can improve performance by sending UPDATE statements in a batch. This is beneficial when you have a lot of update (more than 75%) in your application. You can configure to how many of UPDATE statements to batch together to go out to the database in one round trip by setting the batch-size element in entity-deployment tag for your entity bean in the orion-ejb-jar.xml. The default value for batch-size is 1 i.e. updates are not batched.
There is one exception to the use of batch-size i.e. if the application code requires execution of a SELECT statement within several UPDATE statements, the updates batched prior to the SELECT statement will be executed against the database before executing the SELECT statement. This is done so that all updates are performed before you retrieve any data. If you know that it does not matter for this SELECT statement to be performed, then you can stop the automatic flushing by specifying delay-updates-until-commit to true for the bean.
Mapping a CMP field and CMR field to the same database row
When you define a relationship between beans, you define a CMP field and then you map a relationship to the bean. Both the CMP field and the relationship eventually map to the same row in the database. For instance, in the employee bean, a department ID is specified as a CMP field.
When you define the CMR relationship between the employee and the department bean, the employee/department relationship is mapped through a CMR defined variable (dept) that is mapped to the employee bean's department ID. Since both fields map to the same row in the database, you must specify that one of these fields cannot be changed through the shared attribute. The shared attribute makes the particular CMP or CMR field read-only. Thus, to define that the CMP field, deptID, cannot be modified, do the following:
<cmp-field-mapping name="deptID" shared="true" persistence-name="deptID" />
Defining the above in the employee entity bean states that the deptID field is "shared" and that you cannot modify the deptID to be another value through the setDeptID method. Instead, if you needed to modify the relationship, you would have to modify the relationship through the CMR relationship variable, dept, with the setDept method, pointing the employee entity bean to another bean (and thus, another row in the database).
In the case of complex primary keys, if you have a CMR field as part of the relationship, you can define it as shared, and then it takes on the same attribute as a primary key in that no one can modify it after it is initially set.
2:57:47 PM 
|
