Tuning WebLogic Server EJBs 10-5
See Relationship Caching in Programming WebLogic Enterprise JavaBeans for Oracle WebLogic Server.
In this release of WebLogic Server, if a CMR field has specified both relationship-caching
and cascade-delete, the owner bean and related bean are loaded to SQL which can provide an additional performance benefit.
10.4.1.1 Using Inner Joins
The EJB container always uses an outer join in a CMP bean finder when eager relationship-caching
is turned on. Typically, inner joins are faster to execute than outer joins with the drawback that inner joins do not return rows which do not
have data in the corresponding joined table. Where applicable, using an inner join on very large databases may help to free CPU resources.
In WLS 10.3, use-inner-join has been added in weblogic-cmp-rdbms-jar.xml
, as an attribute of the weblogic-rdbms-bean, as shown here:
weblogic-rdbms-bean ejb-nameexampleBeanejb-name
... use-inner-jointrueuse-inner-join
weblogic-rdbms-bean This element should only be set to true if the CMP beans related beans can never be
null or an empty set. The default value is false. If you specify its value as true, all relationship cache query
on the entity bean use an inner join instead of a left outer join to execute a select query clause.
10.4.2 Use JDBC Batch Operations
JDBC batch operations are turned on by default in the EJB container. The EJB container automatically re-orders and executes similar data base operations in a single batch
which increases performance by eliminating the number of data base round trips. Oracle recommends using batch operations.
10.4.3 Tuned Updates
When an entity EJB is updated, the EJB container automatically updates in the data base only those fields that have actually changed. As a result the update statements
are simpler and if a bean has not been modified, no data base call is made. Because different transactions may modify different sets of fields, more than one form of
update statements may be used to store the bean in the data base. It is important that you account for the types of update statements that may be used when setting the size
of the prepared statement cache in the JDBC connection pool. See
Section 12.4, Cache Prepared and Callable Statements
.
10.4.4 Using Field Groups
Field groups allow the user to segregate commonly used fields into a single group. If any of the fields in the group is accessed by applicationbean code, the entire group is
loaded using a single SQL statement. This group can also be associated with a finder. When the finder is invoked and finders-load-bean is true, it loads only those
10-6 Performance and Tuning for Oracle WebLogic Server
fields from the data base that are included in the field group. This means that if most transactions do not use a particular field that is slow to load, such as a BLOB, it can be
excluded from a field-group. Similarly, if an entity bean has a lot of fields, but a transaction uses only a small number of them, the unused fields can be excluded.
10.4.5 include-updates
This flag causes the EJB container to flush all modified entity beans to the data base before executing a finder. If the application modifies the same entity bean more than
once and executes a non-pk finder in-between in the same transaction, multiple updates to the data base are issued. This flag is turned on by default to comply with
the EJB specification.
If the application has transactions where two invocations of the same or different finders could return the same bean instance and that bean instance could have been
modified between the finder invocations, it makes sense leaving include-updates turned on. If not, this flag may be safely turned off. This eliminates an unnecessary
flush to the data base if the bean is modified again after executing the second finder. This flag is specified for each finder in the cmp-rdbms descriptor.
10.4.6 call-by-reference
