About Using Client/Server Drivers

Applications that are running in other Pods in your Kubernetes cluster can use your TimesTen database by using the standard TimesTen Client/Server drivers. You must configure your application containers with a TimesTen client instance. That instance must contain a configured $TIMESTEN_HOME/conf/sys.odbc.ini file, or your application must use an appropriate Client/Server connection string.

In TimesTen Classic, if you chose to configure a sys.odbc.ini file, the contents of sys.odbc.ini contains a client DSN definition that references the Pods that are running your TimesTen databases. In TimesTen Scaleout, you can export a sys.odbc.ini file for use by client/server clients outside of the grid. Use the ttGridAdmin utility with the gridClientExport or gridClientExportAll for this purpose. See ttGridAdmin in the Oracle TimesTen In-Memory Database Reference.

This example creates the sample DSN and references the sample TimesTenClassic object in the mynamespace namespace. 

% vi $TIMESTEN_HOME/conf/sys.odbc.ini

[sample]
TTC_SERVER_DSN=sample
TTC_SERVER1=sample-0.sample.mynamespace.svc.cluster.local
TTC_SERVER2=sample-1.sample.mynamespace.svc.cluster.local

Applications connect to the TimesTen database using this DSN. In a TimesTen Classic active standby pair configuration, TimesTen automatically routes application connections to the active database.

Client/Server applications must connect to the database using a defined username and password. The Operator can create such a user with ADMIN privileges. You can then connect to the database as that user to create other users and grant those users the CREATE SESSION privilege. See Overview of Configuration Metadata and Kubernetes Facilities.

In this example, use a connection string to connect to the sample database as the sampleuser user. (If you use a connection string that requires all the required connection attributes, you do not need to define them in the sys.odbc.ini file.) The sampleuser user was created by the Operator and already exists in the sample database. After connecting, you can verify that the sampleuser.emp table exists. (The Operator also previously created this table. See schema.sql for information on how the Operator created this table.) 

% ttIsqlCS -connstr "TTC_SERVER1=sample-0.sample.mynamespace.svc.cluster.local;
TTC_SERVER2=sample-1.sample.mynamespace.svc.cluster.local;
TTC_SERVER_DSN=sample;UID=sampleuser;PWD=samplepw";

 
Copyright (c) 1996, 2025, Oracle and/or its affiliates. All rights 
reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
 
 
connect "TTC_SERVER1=sample-0.sample.mynamespace.svc.cluster.local;
TTC_SERVER_DSN=sample;uid=sampleuser;pwd=********";
Connection successful: 
DSN=;TTC_SERVER=sample-0.sample.mynamespace.svc.cluster.local;
TTC_SERVER_DSN=sample;UID=sampleuser;DATASTORE=/tt/home/timesten/datastore/sample;
DATABASECHARACTERSET=AL32UTF8;CONNECTIONCHARACTERSET=AL32UTF8;PERMSIZE=200;
DDLREPLICATIONLEVEL=3;
(Default setting AutoCommit=1)
Command> tables;
  SAMPLEUSER.EMP
1 table found.

If you are using TimesTen client/server from applications within your Kubernetes cluster, you do not have to list all the TimesTen Pods in your connection string. Instead, you can create a Kubernetes Service that routes incoming client connections to ready instances. For this Service to work correctly, you need to use a readiness probe.

If you are using TimesTen client/server from applications outside your Kubernetes cluster, you must use a Kubernetes NodePort Service and a readiness probe.

For more information: