Persistence Layer and Databases

Use

Persistent Cluster Configuration Database

The SAP Web AS Java uses the system databases to store all binaries and configuration information with the Configuration Manager. Therefore, this database is essential for SAP Web AS Java to function correctly.

When the configuration database fails, the Web AS Java tries to reconnect to the database. When the database is brought online, the cluster becomes functional again.

If the database is no longer available, you have to stop the Web AS Java manually as it is not able to reconnect to the database.

Availability of Database Access Layer

Depending on the programming model used for database access in your applications, SAP Web AS Java provides the following reconnect mechanisms:

?     Connections using OpenSQL and NativeSQL with Java Database Connectivity (JDBC)

OpenSQL is SAP’s database abstraction layer that translates abstract SQL statements to native database SQL statements. When the database becomes unavailable, the database connections in the pool become unusable, but are not closed.

Each of the “old” connections is closed on the first attempt to be used. After the database goes online again and all old connections in the pool have been closed, it is possible to create new connections to the database and work with persistent data. New connections are created on demand. Applications need to react to this by closing connections and reconnecting in the event of failure.

SAP recommends you to use OpenSQL as standard when connecting to the database schema of SAP Web AS Java, or NativeSQL if you do not want to use OpenSQL.

?     Connections using VendorSQL with direct JDBC connection

The J2EE Server maintains a pool of database connections. The real database connections become transparent to the application. There is no reconnect mechanism if you use the database driver through a DriverManager.

If you use the driver through a DataSource, you can use the standard techniques of receiving error events (through the ConnectionEventListener) as described in the JDBC 2.0 Standard Extension API. However, implementation of this technique differs for each driver vendor. Therefore you need to consult the documentation of your driver product for more information.

 

Generally, the application itself has to attempt to re-establish a database connection when database access fails.