email article printer friendly

More Object Persistence Choice Factors
In this second of four installments, object query mechanisms and transaction state management are discussed as critical factors in deciding on the right object persistence technology.
By Dr. Wilson Cheng and Dr. Pinaki Poddar

In the first installment of this discussion, "Choose the Right Object Persistence" (Java Pro online, July 16, 2003), we covered the mapping support and domain models of JDBC, CMP, and JDO as factors you should consider in deciding on your object persistence technology. Now let's turn to object query mechanisms and transaction state management as additional factors in your decision.

In general, existing objects in a data store are accessed more frequently than new objects are created. The object query mechanism is therefore another critical issue in object persistence. Important factors characterizing a query mechanism are: How does an application specify a database query? How powerful is the query expression language? And, in what form does the data store return query results? JDBC uses SQL, CMP uses EJB-QL, and JDO uses JDO-QL. These query mechanisms are unique.

The most important difference is that while SQL queries refer directly to the data store schema, both EJB-QL and JDO-QL specify the query in their object models. The second critical difference is the way a query is specified. JDBC applications send a query directly to the data store as String arguments to the methods of java.sql.Statement.

Queries in EJB are declarative—abstract finder methods on the bean interface. The deployment descriptor defines how the finder is realized in EJB-QL. The EJB compiler translates an EJB-QL query to the syntax of the target data store. The compiler also inserts execution statements in the automatically generated concrete bean class.

Queries in JDO follow a programmatic approach using Java-like syntax. A JDO query is represented as an instance of a javax.jdo.Query object, with predicates, parameters, and variables specified on a Query instance. Predicates, parameters, and variables refer only to elements in the Java application space; the JDO driver at runtime translates the query into the syntax of the target data store when the execute() method is invoked on a Query object.

Aggregational queries compute statistics of sets of records and are natural to RDBMSs designed for set operations. JDBC and SQL perhaps remain unsurpassed in power of expression for selecting RDBMS records with aggregational queries. The major benefit is that computational load is on the RDBMS. For example, to compute the average salary of all employees, a JDBC application issues a single SQL statement, the RDBMS server computes the average, and the JDBC driver returns a single number. Compare this streamlined process to application-centric query mechanisms such as EJB-QL or JDO-QL, in which the average salary computation results in fetching employee instances from the data store to the client, where computation occurs.

A navigational query is the capability of accessing related instances from a given instance. For example, a particular department might be selected, and then an employee of that department is needed. In the domain model, the Department object contains the Employees as a collection. In such cases, as application code iterates through the collection of Employees, a CMP or JDO driver implicitly fetches Employee instances from the data store, but with JDBC the application must issue an explicit SQL query to fetch Employee records.

Will EJB-QL or JDO-QL ever match SQL's power? EJB-QL is approaching SQL-like syntax and capabilities. JDO queries also allow alternative syntax in a particular JDO driver. In principle, a JDO driver for RDBMS may allow your application to use direct SQL. However, the design focus in CMP and JDO is to separate the domain object model from the schema and data store. As such, CMP and JDO cannot assume specific query capabilities of the data store.