Java Persistence Infrastructure 
Overview
The J2EE Engine supports both relational and object persistence based on the following programming models:
· Open SQL/JDBC and Open SQL/SQLJ on the relational side
· JDO and EJB CMP on the object-relational side
All these programming models are based on a common persistence infrastructure within the J2EE Engine. The infrastructure is built on an SQL engine that processes all SQL statements created anywhere within the Java server. The main tasks of the SQL engine are to achieve:
· Portability of the Open SQL language subset across all database platforms supported by SAP
· Performance optimizations through client-side data buffering
· Easy maintenance by appropriate database-independent monitoring and tracing facilities.
Java Persistence Layers
The following graphic provides an architectural overview of the particular components of the persistence infrastructure within the J2EE Engine. The SQL engine itself consists of three JDBC layers that build on each other.
Open JDBC
The top-layer interface in the Open SQL for Java framework is Open JDBC API. It defines a portable subset of both the SQL language and JDBC methods with regard to the database platforms supported by SAP. In addition, support for SQLJ is provided within the Open SQL/SQLJ framework. All SQL statements that are issued through the Open JDBC API are automatically checked against the Open SQL Grammar.
The semantic checks performed by the Open JDBC parser are based on catalog information, which is provided by a database-independent API (the so-called catalog API) for all tables that have been defined and deployed using the Java Dictionary in the SAP NetWeaver Developer Studio. Open JDBC evaluates exactly the meta information provided by the Java Dictionary. Therefore, Open JDBC relies on an exact structural correspondence between a table definition in the dictionary and the real structure of the table in the database. This correspondence is guaranteed if structural changes on database tables are exclusively performed through the deployment tool of the SAP NetWeaver Developer Studio. The structure of a database table must not be changed by native database means because otherwise Open JDBC may use invalid meta information when accessing a table.
The Open JDBC layer provides the following important features:
· Table buffer
The purpose of the table buffer is to speed up database queries by keeping frequently requested rows of a database table in a client-side buffer. It is completely transparent to the application program – that is, to take advantage of the buffer, you are not required to write specific code. It is decided at design time in the Java Dictionary whether a certain database table is buffered or not, and if so, which parts of it are to be buffered. For more information, see Table Buffer.
· SQL trace
This is an on-demand log of selected SQL statements issued against the database using Open JDBC. For more information, see SQL Trace.
· Statement pooling
This feature improves performance by providing a cache of SQL statements that are used repeatedly. For more information, see Statement Pooling.
Native JDBC
The Native JDBC API provides direct access to the database and allows you to fully exploit the functionality of the underlying database system. Unlike Open SQL, the Native SQL implementation performs no checks regarding the portability of SQL statements or JDBC methods. All method invocations are passed through to the underlying vendor JDBC driver unchanged. The implementation of the Native JDBC API is simply a wrapper around the vendor-specific JDBC driver, but also provides two important enhancements:
· SQL Trace
Vendor JDBC
The concept of vendor JDBC implies the database platform specific JDBC driver that comes either from the database vendor or from a third party. SAP supports a set of JDBC drivers that have been thoroughly tested on the various database platforms. For more information, see the relevant installation guides on SAP Service Marketplace at service.sap.com/instguides.