When True Cache is configured, applications must decide whether to query data from True Cache or the primary database. There are two ways to do this:
- The application maintains two physical connections: one to the primary database and one to True Cache. Each connection has a database application service, and the application chooses which connection to use based on whether it's reading or writing. You can use this model with any existing client drivers and any programming language.
The application sends queries that don't need to see the most current data to True Cache through a True Cache database application service. The application sends other queries and updates to the primary database through the primary database application service. - The application maintains one logical connection that uses the database application service for the primary database. The JDBC Thin driver (starting with Oracle Database 23ai) maintains physical connections to the primary database and True Cache. This model only works with Java applications.
The application switches from True Cache to the primary database without having to specify an instance name. The application uses special calls to flag the logical connection as read-only or read-write. If it's read-only, the query is sent to True Cache. Otherwise, it's sent to the primary database.
The JDBC method is illustrated by the application code in the diagram.
- The client application creates a logical connection to connect to the primary database application service called
SALES
by using the connection'suseTrueCacheDriverConnection
parameter. - The application flags the logical connection as
setReadOnly(true)
orsetReadOnly(false)
to direct SQL statements to True Cache or the primary database, respectively. For each logical connection, the JDBC Thin driver internally maintains two physical connections: one to the primary database and one to True Cache. Both connections were associated when the database application serviceSALES
was created.