Typically, databases that support storing client information do so by providing a register, a variable, or a column in a system table in which the information is stored. If an application attempts to store information and the database does not provide a mechanism for storing that information, the driver caches the information locally. Similarly, if an application returns client information and the database does not provide a mechanism for storing that information, the driver returns the locally cached value.
For example, let’s assume that the following code returns a pooled connection to an Oracle database and sets a client application name for that connection. In this example, the application sets the application name SALES157 using the driver property ApplicationName.
// Get Database Connection
Connection con = DriverManager.getConnection(
"jdbc:datadirect:oracle://server3:1521;SID=ORCL;
ApplicationName=SALES157","TEST","secret");
...
The application name SALES157 is stored by the DB2 database in the CURRENT CLIENT_APPLNAME register, the location that DB2 reserves for this information. When the connection to the database is closed, the connection is returned to the connection pool as usual and the client information on the connection is reset to an empty string.
The application name SALES157 is stored locally by the database. When the connection to the Oracle database is closed, the client information on the connection is reset to an empty string. If we used this same scenario against a MySQL database, which does not support storing client information, the driver would store the application name locally.
