JPA Read-Only Entities
The JPA specification does not directly address the notion of a read-only entity, but many
JPA providers do. A read-only entity will usually offer much better performance than a (de-
fault) read-write entity, because the JPA implementation knows that it does not need to keep
track of the state of the entity, nor enroll the entity in transactions, nor lock the entity, and so
on. In Java EE containers, read-only entities are often supported regardless of the JPA imple-
mentation used. The application server in that case ensures that the entities are accessed us-
ing a special, nontransactional JDBC connection. This usually offers a significant perform-
In a Java EE container, transaction support for read-only entities is one area that the JPA spe-
cification does address: a business method that is annotated with @TransactionAttrib-
uteType.SUPPORTS can be run outside a transaction (assuming no transaction is in progress
when that method is called).
In that case, the entities accessed in that method must be, essentially, read-only, since they
are not part of a transaction. However, if the method is called from another method that is
part of a transaction, the entities still become part of the transaction.
Properly tuning JDBC and JPA access to a database is one of the most significant ways to af-
fect the performance of a middle-tier application. Keep in mind these best practices:
▪ Batch reads and writes as much as possible by configuring the JDBC or JPA configura-
▪ Optimize the SQL the application issues. For JDBC applications, this is a question of ba-
sic, standard SQL commands. For JPA applications, be sure to consider the involvement
of the L2 cache.
▪ Minimize locking where possible. Use optimistic locking when data is unlikely to be
contended, and pessimistic locking when data is contended.
▪ Make sure to use a prepared statement pool.
▪ Make sure to use an appropriately sized connection pool.