25 Optimizing Persistence Applications for Oracle Exalogic

This chapter provides instructions for enabling and configuring features that can optimize how persistence applications perform on Oracle Exalogic.

This chapter includes the following sections:

Use Case

Applications want to increase performance by taking advantage of the extreme performance and scalability of the Oracle Exalogic platform.

Solution

The implementation is achieved by enabling Exalogic optimizations as required.

Components

Samples

See Section 25.3, "Additional Resources" for links to samples.

25.1 Introduction to the Solution

Oracle Exalogic provides a foundation for extreme performance, reliability, and scalability. Persistence applications can take advantage of this foundation by using optimizations that provide increased performance and better resource utilization. The optimizations include: an Exalogic-specific tuner and profiler, an Exalogic-specific batch writer, an Exalogic-specific serialized object policy implementation, and Exalogic-specific cache coordination enhancements.

Note:

  • Exalogic optimizations are designed to address specific application use cases and may not increase the performance of all applications.

  • Oracle Exalogic optimizations are not intended to replace general tuning recommendations. Applications should always be properly tuned before testing the Exalogic optimizations. For details about performance tuning, see "Enhancing Performance".

25.2 Implementing the Solution

The tasks in this section provide general instructions for using optimizations that take advantage of the extreme performance and scalability of the Oracle Exalogic platform.

Note:

Performance tests should always be used to validate the optimization for a deployed application.

25.2.1 Task 1: Enable the Exalogic Automated Tuner

Automated tuning is an optimization that allows applications to automatically tune JPA and session configuration for a specific purpose. Automated tuning facilitates a one-flag configuration option for configuring multiple settings or for performing dynamic tuning. The use of automated tuning in micro-benchmark tests that contained a mix of insert updates and reads showed a reduction in CPU (both on the middle tier and database tier) and a reduction in memory usage. The use of automated tuning in CRUD and query micro-benchmark tests showed an increase in performance against tests that did not use the optimization. For details about automated tuning, see "Automated Tuning".

TopLink includes an automated tuner that provides an optimized configuration for the Exalogic platform. It enables multiple performance features and enables an Exalogic-specific profiler. The profiler monitors the startup phase of the application and detects queries that trigger the n+1 query execution problem. It then optimizes these queries to use batch fetching. For dynamic queries that cannot use batch fetching, it further analyses these queries and defines a runtime state machine to detect and optimize these queries. For details about profilers, see "Performance Optimization Recommendations and Tips".

When using the Exalogic tuner, the following persistence unit properties are set prior to deployment:

Note:

If a property is explicitly set (such as in the persistence.xml file), then it takes precedence over the properties that are automatically set by the Exalogic tuner.

WEAVING_EAGER = true
CACHE_SIZE_DEFAULT = 1000
QUERY_CACHE = true
ORDER_UPDATES = true
BATCH_WRITING = JDBC
PERSISTENCE_CONTEXT_CLOSE_ON_COMMIT = true
PERSISTENCE_CONTEXT_FLUSH_MODE = Commit
DDL_GENERATION_INDEX_FOREIGN_KEYS = true
PROFILER = oracle.toplink.exalogic.tuning.TuningAgent
FREE_METADATA = true

If connection pooling is used, then statement caching for the session is automatically enabled. In addition, after deploying and connecting to the session, the Exalogic tuner automatically sets the session to use the Exalogic-specific DynamicParameterizedHybridBatchWritingMechanism batch writer. For details about batch writing, see "Task 4: Configure Heterogeneous Batch Writing on Exalogic".

To enable the Exalogic tuner, specify ExaLogic as the value of the eclipselink.tuning property in the persistence.xml file. For example:

<property name="eclipselink.tuning" value="ExaLogic"/>

On Oracle WebLogic Server, the Exalogic automated tuner can be enabled with the console using the domain Configuration | General tab and selecting the Enable Exalogic Optimizations option, or it can be enabled through the DomainMBean.ExalogicOptimizationsEnabled MBean attribute.

25.2.2 Task 2: Use Serialized Object Policy on Exalogic

Serialized object policy allows TopLink to write out the whole entity object (in binary format) with its privately owned (and nested privately owned) entities and element collections into an additional field in the database. Serialized object policy is best for read-only or read-mostly applications and should only be used for entities that load all their dependent entities or element collections. The greatest increase in performance is for data models with many graph levels. For most simple objects, the use of serialized object policy degrades performance.

For detailed information about configuring serialized object policy and when it is best used, see "Serialized Object Policy".

TopLink includes the oracle.toplink.exalogic.sop.SerializedObjectPolicy implementation for use on the Exalogic platform. To use the policy, include the @SerializedObject annotation on an entity or mapped superclass and pass in the implementation. For example:

@Entity
@SerializedObject(oracle.toplink.exalogic.sop.SerializedObjectPolicy.class)
@OptimisticLocking(cascade = true) 
public class Employee implements Serializable {... 

@Entity
@SerializedObject(oracle.toplink.exalogic.sop.SerializedObjectPolicy.class, 
   column = @Column(name="ADDR_SOP"))
@OptimisticLocking(cascade = true)
public class Address implements Serializable {...

25.2.3 Task 3: Use Cache Coordination with WebLogic Server Clusters on Exalogic

Cache coordination synchronizes changes among distributed sessions. Cache coordination is most useful in application server clusters to maintain consistent data across all applications. For details about using cache coordination, see "Using Cache Coordination".

Cache coordination has been optimized for Exalogic and WebLogic Server and naturally benefits from running on these platforms. Integration with WebLogic Server JMS (when using cache coordination with JMS) takes advantage of improvements with JMS on Exalogic. In addition, Exalogic allows TopLink applications to automatically use WebLogic Server clusters for cache coordination without any additional configuration. This allows applications to take advantage of WebLogic Server cluster messaging, which has been optimized to run over Infiniband.

Lastly, cache coordination on WebLogic Server can be configured to use Portable Object Format (POF) serialization. POF serialization is designed to be more efficient in both space and time than other serialization formats.

To use POF with cache coordination, include the eclipselink.cache.coordination.serializer property in the persistence.xml file and set it to toplink.exalogic.serializers.POFSerializer. For example:

<property name="eclipselink.cache.coordination.serializer"
   value="toplink.exalogic.serializers.POFSerializer"/>

25.2.4 Task 4: Configure Heterogeneous Batch Writing on Exalogic

Heterogeneous batch writing is an optimization that allows multiple heterogeneous dynamic SQL statements to be sent to the database and executed as a single batch. Heterogeneous batch writing is best used for transactions that involve multiple writes and reduces network access for write operations. The use of heterogeneous batch writing in micro-benchmark tests showed an improvement in performance against tests that did not use the optimization. For details about batch writing, see "Batch Writing".

TopLink includes two batch writing implementations for Exalogic that allow multiple heterogeneous parameterized SQL statements to be sent to the database and executed as a single batch. JDBC batch writing does not allow this, so a parameterized anonymous block of SQL is used instead. A counter output parameter is used to return the row count for optimistic locking. The implementations are:

  • oracle.toplink.exalogic.batch.DynamicParameterizedBatchWritingMechanism

  • oracle.toplink.exalogic.batch.DynamicParameterizedHybridBatchWritingMechanism

Note:

The DynamicParameterizedHybridBatchWritingMechanism batch writer implementation is automatically enabled when using the Exalogic automated tuner. See "Task 1: Enable the Exalogic Automated Tuner".

To explicitly enable the DynamicParameterizedHybridBatchWritingMechanism batch writing implementation, include the eclipselink.jdbc.batch-writing property set to ExaLogic and the eclipselink.jdbc.batch-writing.size properties in the persistence.xml file. For example:

<property name="eclipselink.jdbc.batch-writing" value="ExaLogic"/>
<property name="eclipselink.jdbc.batch-writing.size" value="150"/>

The implementations can also be explicitly entered as the value of the property. For example:

<property name="eclipselink.jdbc.batch-writing"
   value="oracle.toplink.exalogic.batch.
      DynamicParameterizedHybridBatchWritingMechanism"/>
<property name="eclipselink.jdbc.batch-writing.size" value="150"/>

25.3 Additional Resources

See the following resources for more information about the technologies and tools used to implement the solutions in this chapter:

The following code sample and JavaDoc resources are available: