How do you optimize EclipseLink performance for a high-throughput application?

Most EclipseLink performance work comes down to reducing the number and size of round-trips to the database, and making sure the framework's own caching and tracking features are working with the application rather than against it.

• Enable and tune the shared cache - use @Cache with appropriate size and expiry per entity so frequently-read, rarely-changed data is served from memory instead of round-tripping to the database.
• Use batch fetching for relationships - apply eclipselink.batch hints wherever a collection is routinely accessed for every row in a result set, avoiding N+1 query patterns.
• Use fetch groups for wide entities - avoid loading large or rarely-needed attributes (BLOBs, long text fields) on queries that don't need them.
• Mark true read-only data as such - the eclipselink.read-only hint or a read-only cache policy skips change-tracking overhead entirely for entities that are never updated.
• Ensure weaving is actually active - confirm attribute change tracking (not deferred detection) is in effect, since it avoids the cost of cloning and diffing whole objects at commit time.
• Tune JDBC connection pooling and batch writing - enable eclipselink.jdbc.batch-writing so multiple INSERT/UPDATE statements are sent to the database together rather than one round-trip per statement.

The highest-leverage changes tend to be batch fetching plus batch writing together: one addresses read-side N+1 patterns, the other addresses write-side round-trip overhead, and together they typically account for the bulk of the performance gap between a naive EclipseLink setup and a well-tuned one.