Though the value varies, JDBC drivers will typically set the default fetch size to a fairly
small number. That approach is reasonable in most circumstances; in particular, it is very un-
likely to lead to any memory issues within the application. If the performance of the next()
method (or the performance of the first getter method on the result set) is particularly slow
every now and then, consider increasing the fetch size.
1. Applications that process large amounts of data from a query should consider
changing the fetch size of the data.
2. There is a trade-off between loading too much data in the application (putting
pressure on the garbage collector) and making frequent database calls to retrieve a
set of data.
The performance of JPA is directly affected by the performance of the underlying JDBC
driver, and most of the performance considerations regarding the JDBC driver apply to JPA.
JPA has additional performance considerations.
JPA achieves many of its performance enhancements by altering the bytecodes of the entity
classes. In a Java EE environment, this happens transparently. In a Java SE environment, it is
very important to make sure that the bytecode processing is set up correctly. Otherwise, JPA
application performance will be unpredictable: fields that are expected to be loaded lazily
might be loaded eagerly, data saved to the database might be redundant, data that should be
in the JPA cache may need to be refetched from the database, and so on.
There is no JPA-defined way for the bytecodes to be processed. Typically, this is done as part
of compilation—after the entity classes are compiled (and before they are loaded into JAR
files or run by the JVM), they are passed through an implementation-specific postprocessor
that “enhances” the bytecodes, producing an altered class file with the desired optimizations.
Some JPA implementations also provide a way to dynamically enhance the bytecodes as the
classes are loaded into the JVM. This requires running an agent within the JVM that is noti-
fied when classes are loaded; the agent interposes on the classloading and alters the bytes be-
fore they are used to define the class. The agent is specified on the command line of the ap-