General Tuning Tips

To substantially improve your application efficiency and throughput, Table 10-1 lists several tuning areas and offers tips to obtain the best performance from your OracleAS TopLink application.

Table 10-1 Tips for Building Efficient OracleAS TopLink Applications

Area	Recommendations	Related Information
General	Do not override OracleAS TopLink default behavior unless your application absolutely requires it. Because OracleAS TopLink default behavior is set for optimum results with the most common applications, the default is usually the most efficient choice for any given option. This is especially important for query or cache behavior.
Mapping	Use indirection whenever possible, especially in cases in which a class is normally used without its related objects.	See "Indirection".
Descriptors	Do not use checkCacheThenDatabase on descriptors unless required by the application. Query default behavior offers better performance.	See "Cache Usage". See "Advanced Finder Options".
	Use conformResults on queries only when required. This avoids unnecessary resource overhead.	See "Validating a Unit of Work". See "Cache Usage". See "Advanced Finder Options".
Queries	If possible, use named queries in your application. Named queries help you avoid duplication, are easy to maintain and reuse, and easily add complex query behavior to the application.	See "Predefined Queries".
	Use parameterized SQL to improve write performance. Parameterized SQL improves performance by reusing the same prepared statement for multiple executions. This reduces overhead.	See "Binding and Parameterized SQL". See "Parameterized SQL".
Sessions	Do not pool client sessions. Pooling sessions offers no performance gains.	See "Client Session".
	With JTA transactions, use getActiveSession() to access the active session for the current external transaction.	See "J2EE Integration".
	Use the OracleAS TopLink client session instead of remote session. Client session is appropriate for most multi-user J2EE application server environments.	See "Client Session". See "J2EE Integration".
Unit of Work	When you read objects, use the Unit of Work only when the objects returned from a query will be modified.	See "Transactions".
Cache	Tune the OracleAS TopLink cache for each class to help eliminate the need for distributed cache synchronization. Always tune these settings before implementing cache synchronization.	See "Setting Class Information" in the Oracle Application Server TopLink Mapping Workbench User's Guide.
	Use Weak Cache for particularly volatile objects.	See "Working with Identity Maps" in the Oracle Application Server TopLink Mapping Workbench User's Guide.
Cache Synchronization	Do not use distributed cache synchronization unless it is required by your application. Distributed cache synchronization offers performance benefits only in clustered environments in which several servers in the cluster regularly request and update the same objects.	See "Distributed Cache Synchronization".
	Use Java Message Service (JMS) for cache synchronization rather than Remote Method Invocation (RMI). JMS is more robust, easier to configure, and runs asynchronously. If you require synchronous cache synchronization, use RMI.	See "Distributed Cache Synchronization".
Code	Use OracleAS TopLink Mapping Workbench rather than hand-coding. OracleAS TopLink Mapping Workbench is easy to use, and implements many OracleAS TopLink features for you automatically.
	Use instance or static variables to cache the results of resource-intensive computations.
	If you use RMI or CORBA, avoid fine grain remote message sends.