Preparing applications for use with Universal Cache
At minimum, you need to make your application to connect to the Universal Cache system using the solidDB® JDBC Driver or solidDB® ODBC Driver, instead of (or in addition to) connecting to the backend driver.
Additionally, to minimize the changes needed in the application, you can create mappings of backend-specific SQL statements and error messages against the solidDB® statements and error messages.
Integrating an existing application to work with Universal Cache
Conceptually the migration to Universal Cache can mean that an existing enterprise data server is simply replaced with a cache database that sits between the backend database and application, making the database appear faster from an application perspective. There are no changes in the database interface layer.
In reality, the conversion from single database system to a cache database system is likely to require changes in the application. For example, the following considerations might require code changes:
▪The application must be aware of the properties of two database connections, one to the cache database and the another to the backend database.
The SQL passthrough functionality can mask the two connections to one ODBC or JDBC connection but will require awareness of the two databases in error processing.
▪Queries and transactions combining data from the cache and backend databases are not supported. A combination of backend and cache database is not fully transactional although both individual components are transactional databases.
However, creating a transactional combination of two or more databases is possible using Distributed Transactions. A Distributed Transaction is a set of database operations where two or more database servers are involved. The database servers provide transactional resources. Additionally, a Transaction Manager is required to create and manage the global transaction that runs on all databases. solidDB® supports the standard Java Transaction API (JTA), through providing a set of XA classes. JTA methods enable the Transaction Manager to control solidDB® as one of the transactional resources in a global transaction.
▪SQL compatibility between the solidDB® server and the backend data server might be limited.
Generally, the applications that have been implemented directly using JDBC or ODBC APIs, or a middleware running on top of those APIs, might require no conversion at all. If no extensions to the SQL Standard are used, the applications are expected to work with minor modifications.
Because stored procedure languages are not compatible with each other, a rewrite for stored procedures will be required if they are used in the application. This can be automated to some level but a separate project is necessary for stored procedure conversion.
If you use APIs, access methods, or programming paradigms that are not supported by solidDB® (such as embedded SQL), and there is no ODBC or JDBC-based middleware available to act as a gateway, you need to rewrite parts of the application.