Depending on your Oracle version, the feature is implemented in the method
setEndToEndMetrics (It has been deprecated since 12.1 in favor of setClientInfo())
or setClientInfo
Here a small example of the usage. The client (your service) after acquiring a connection (typically from a connection pool) sets the properties
action
, clientId
and module
String[] metrics = new String[OracleConnection.END_TO_END_STATE_INDEX_MAX];
metrics[OracleConnection.END_TO_END_ACTION_INDEX] = 'myAction1';
metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = 'myClient';
metrics[OracleConnection.END_TO_END_MODULE_INDEX] = 'myModule1';
con.setEndToEndMetrics(metrics, (short) 0);
and resets them before returning the connection.
The DBA
may observe the setting in the V$SESSION
with the following query
select sid, client_info, module, action from v$session
so she is possible to relate the database session no only with the service, but the combination of client / module and action may provide further details of the state of the service.
Three things are important to consider:
This work only if all services establish certain discipline in setting the values. While re-using the sessions from the connection pool it is easy to "inherit" a wrong setting from a predecessor service. I'd recomment to implement it as an aspect of the connection pool resource handling.
Further the Java version, JDBC driver and Oracle Server must have compatible versions, so it is a good practice to test the functionality in a simple script.
Finaly DON'T use for the setting the PL/SQL API (which a PL/SQL developer would naturally do). The great difference is that the PL/SQL API triggers a roundtrip to the database, while JDBC API not (the values are send with the next request).