Factor in Performance and Portability
Discover the impact of performance and scalability as well as portability in choosing an object persistence technology in this third of four installments
by Dr. Wilson Cheng and Dr. Pinaki Poddar
In previous installments of this discussion—"Choose the Right Object Persistence" (Java Pro online, July 16, 2003) and "More Object Persistence Choice Factors" (Java Pro online, July 23, 2003)—we covered the mapping support and domain models of JDBC, CMP, and JDO as well as object query mechanisms and transaction state management as factors to consider in choosing an object persistence technology. Here we'll discuss performance and scalability and portability as additional factors in your decision.
To choose the right object persistence technology, you must understand what performance optimizations they offer. Performance issues are not an explicit part of the JDBC, CMP, or JDO specification. However, applications still must be able to scale against large data sets and concurrent accesses. Technology providers boost performance with techniques such as client caching and fetch-on-demand. Because technology providers offer such optimizations as extensions, these optimizations are some of the most distinguishing features among solutions.
Client caching is an in-application-memory cache that retains instances fetched from the data store, even across transaction boundaries. Application requests for objects are first looked up in cache. They are brought from data store only when a requested object is not in cache. In-memory caching avoids redundant fetching of the same instance by different parts of the application, which is a significant performance gain.
Fetch-on-demand or lazy fetching is a technique whereby fields of an instance are brought from storage only when they are accessed. Consider a typical example where an Employee record has a social security number, name, and photograph. When an Employee instance is realized from data store, only its SSN and name fields are fetched. The photograph is fetched only if the user explicitly requests it later, saving the transfer of large volumes of image data.
Optimization requires persistence service to manage domain objects. For object persistence service to optimize performance, it must have the knowledge of the domain objects. Such is the notion of managed objects. In both CMP and JDO, the service provider manages domain objects in these manners: CMP requires the domain objects to be declared as entity beans—the container can then optimize the access of entity beans—and JDO requires the domain objects to be enhanced to implement the PersistenceCapable interface.
With managed objects, both CMP and JDO can implement performance optimizations by controlling an object's interaction with the data store. In JDBC, however, the driver has no notion of managed objects. Thus, performance optimization is fairly limited in JDBC.
JDBC has no built-in performance optimization. A developer must explicitly design JDBC performance optimizations. Fetch-on-demand, for example, can be built into a JDBC application with SQL query projections. However, the development cost of such nontrivial performance optimizations can be great.
Likewise, building a client cache in JDBC is nontrivial. No conceptual or natural association exists between an object and a data store record. On the other hand, prerequisite for a client cache is that objects have persistent identity (such as the primary key of an RDBMS record), and this persistent identity is associated with transient identity implicitly assigned by the Java Virtual Machine (JVM).
The JDBC-prepared query (in the form of a java.sql.PreparedStatement) is a useful performance optimization. If the RDBMS supports prepared query, frequent queries can be instantiated once but executed repeatedly. The cost of query parsing and query plan generation is often comparable to that of query evaluation-prepared queries that can accept different parameters at execution and may result in significant performance gain.
Back to top
|