Revision as of 16:17, 5 March 2008

Design Specification: Performance and Concurrency

ER 221546

Document History

Project overview

This project groups several smaller performance related bug fixes and enhancements into a single unit. Its' goal is the improve the performance, concurrency and scalability of the product.

Concepts

Performance is concerned about reducing CPU usage and finding more optimal methods of processing operations.

Concurrency is concerned with reducing contention and improving multi-threaded and multi-CPU performance.

Scalability is concerned with clustering, large workloads and data.

Requirements

There are no specific requirements for this project; the only real requirement is to ensure that our product remains the leading high-performance persistence solution. Areas of improvement are determined through performance comparison with other persistence products and benchmarking.

Design Constraints

The goal of the project is to improve performance of common usage patterns. Fringe features and usage patterns will not be specifically targeted unless found to be highly deficient.

Functionality

Each specific performance improvement is discussed seperately below.

EntityManager.getReference() Proxies

Requirement

The JPA spec provides a find() and a getReference(), find should query the database for the instance, getReference should return a "proxy" stand-in for the object. Currently getReference() does a find(), it should instead return a proxy. This will significantly improve the performance of the operation. The main usage of this API is to allow an object to be inserted/updated with references to other objects, without requiring to read those objects.

Design

Fetch groups will be used to build an unfetched proxy. A new instance will be create, its' primary key set and given a fetch-group composed of its' primary key attributes. It will be registered with the UnitOfWork.

Testing

• getReference() without weaving
• getReference() outside a transaction
• getReference() and access to a get method
• getReference() and update to a set method
• getReference() used in an update of another object
• getReference() used in an insert of another object

Indirection with EAGER

Requirement

Currently if EAGER relationships are used there are two main performance side-effects:

• Change tracking is disabled.
• Deferred cache locks are used.

It should be possible to use EAGER relationships and not suffer these performance issues.

Design

Provide an option to still enable indirection in the mappings, but instantiate the indirection eagerly. An isLazy option will be added to ForeignReferenceMapping, if eager weaving is enabled the mapping will always be configured to use indirection and indirection will be weaved even if eager. After building an object (and releasing the cache lock), the ObjectBuilder will instantiate all eager relationships.

Testing

• weaving test to ensure object with eager relationship is still weaved for indirection and change tracking
• if not the default, run entity manager tests with eager weaving option set.

Testing

Both the existing performance and concurrency tests and pubic benchmarks will be used to monitor and evaluate performance improvements.

API

• EntityManager.getReference() - Will now return a proxy.

Config files

persistence.xml

• eclipselink.weaving.eager (true/false, default?)

GUI

Documentation

• Document that EntityManager.getReference() now returns a proxy (unfetched) instance, and subsequent access may trigger an ObjectNotFoundException if the object does not exist. Document that fetch-group weaving must enabled (the default when weaving) to allow getReference() to return a proxy, otherwise it does a find().

Open Issues

Decisions

Future Considerations

Continually improve performance.