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.
The following figure provides an architectural overview of the particular components of the persistence infrastructure within the J2EE Engine. The SQL engine consists of three layers that build on each other, as shown on the following figure.
Java Persistence Infrastructure
The topmost layer of the Open SQL for Java framework is designed to provide portability across various database platforms. All SQL statements that are issued through this layer are automatically checked against the Open SQL Grammar.
The topmost layer of Open SQL for Java comprises the following interfaces:
The semantic checks performed by the Open SQL Engine 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 SQL Engine evaluates exactly the meta information provided by the Java Dictionary. Therefore, this layer 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; otherwise Open SQL Engine may use invalid metadata when accessing a table.
The portable SQL 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.
More information: Table Buffer
● SQL Trace
This is an on-demand log of selected SQL statements issued against the database within the Open SQL for Java framework.
More information: SQL Trace
● Statement pooling
This feature improves performance by providing a cache of SQL statements that are used repeatedly.
More information: Statement Pooling
Native SQL provides direct access to the database and allows you to fully exploit the functionality of the underlying database system. Unlike the topmost layer of the Open SQL for Java framework, 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 SQL is simply a wrapper around the vendor-specific JDBC driver, but also provides two important enhancements:
The concept of vendor SQL 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 http://service.sap.com/instguides.