TopLinkPerformance

Built For Speed Interview with MikeNorman. A Word version is also attached to this page. See bottom.

Refer to the TopLink Performance chapter in TopLinkDocumentation for hints on improving performance. forum:277548

Some basic things to consider are:

• Ensure that your connection pool sizes are sufficiently large.
• Use indirection on all relationships.
• Use parameterized SQL, (binding and statement caching).
• Use batch writing (parameterized batch writing).
• Only register objects in the unit of work that you intend to change, make use of read-only setting for objects that are read-only.

To assess/diagnose performance problems, the SessionConsole can be used -- now replaced by the TopLinkWebClient.

Data Integrity

Optimistic Locking

See TopLinkLocking.

Client Session vs. Server Session?

The server session is acquired from the SessionManager?. A client session is acquired with ServerSession?.acquireClientSession.

Reading from the database

Reading more

Joining: for 1-1 relationships, the attribute is joined to and read with the main object in one query. Especially good for back pointers! Warning: joining always does an inner join => can miss valid objects if the attribute doesn't exist.

Batch reading: read all objects at once in a 1-* relationship. Batch reading on 1-1 relationships means the target will be batch read when a ReadAllQuery is run for the parent object (less useful).

Beware of cascading joined/batch read attributes! Can generate a lot of queries.

Reading less

Indirection: don't load the referred object until asked for it. 1-* relationships can be transparent (collections), use ValueHolder for 1-1 relationships.

Partial read: read parts of an object instead of the whole object at once. Beware of primary key issues.

Reading from the session vs. reading from the UOW

The UOW registers any object read through it. This causes the UOW to do extra work when writing and merging UOWs. Objects read through the session do not incur this extra cost -- but they cannot be part of a write.

Bypass cache on read

It is possible to disable the cache on specific read queries. E.g. when the objects are only shown once, and don't need to be copied into the cache.

Cursored streams

Read objects using a cursored stream instead of getting a huge collection that will have to fit in memory.

In-memory Queries

Leverage the cache as much as possible. E.g. all non-primary key queries always go to the database by default! Set checkCacheThenDatabase on specific read object queries to prevent this.

Toplink architect gives rule of thumb for optimization: Regular in-VM call = 1, EJB (remote) call = 10, database call = 100.

Increase cache sizes

Keep some recurrent items in memory at all times by changing the map type to FullIdentityMap and increasing the cache size.

Profiling

The ToplinkSessionConsole? can be used to observe the cache, run queries, etc.

Write Queries

Read-only classes/descriptors

Read-only classes aren't made part of the merge done by the UOW after committing. See javadoc:Descriptor#setReadOnly(): Declaring a descriptor is read-only means that instances of the reference class will never be modified. Read-only descriptor is usually used in the unit of work to gain porformance as there is no need for the registration, clone and merge for the read-only classes.

I've found this on the TopLink discussion forums at Oracle:

Marking a relationship as read-only indicates that the relationship should not be used in the creation of the source object's row for writing. It does not mean that the target class (in this case Error) is read-only. Read-only classes must be set on the project (globally) or on the UnitOfWork (per transaction).

Read-only mappings are typicaly used where multiple mappings provide te same value.

EXAMPLE: The FK of a 1:1 is mapped as a direct-to-field as well as being in the 1:1 relationship mapping. Since they would both result in populating the source object's FK field one of them must be selected to be read-only.

Read objects through session instead of UOW

See above; objects read through a UOW are automatically registered and subjected to the write/merge computation done by the UOW.

Optimize UOW merge

Instead of using deepMergeClone (the most expensive merge option), consider merging objects manually using finer-grained methods. See MergeCloneAPI.

Batch writing

Allows the JDBC driver to batch queries into a single DB call.

Statement binding and caching

Toplink can prepare and cache statements. My tests show a 40% improvement on simple objects.

Preparing/caching Toplink queries

Toplink queries can be prepared and cached just like JDBC statements.

Bypass cache on write

When the changes made to an object don't need to be merged into the cache, the cache can be disabled on specific write queries.

See Also

ConformResultsInUnitOfWork, TopLinkDocumentation, PreparedStatementCaching

Attachments:

BuiltForSpeed.doc

66048 bytes