Question: We are developing microservices using java (Spring and Spring Boot), and the access to our Oracle DB is done via the JDBC Oracle Driver.

The problem is that our DBAs can only see on the Oracle side that a "JDBC Thin Client" is connected. There is no better, logical representation of the connected application. Without such identification, it is hard to know which microservice might be behaving badly. Other non-JDBC clients identify themselves clearly with the hostname.

Is there any way to change the identification String so that it represents a clear identity of the source application/process?

Note: Our system runs on Cloud Foundry which uses containers, so a it's not really possible to provide a machine name or anything like that - a logical application name would be preferred.

Thanks

Answer: 
Thank you everyone for your suggestions,
I have tried them all and sadly they did not work.

This is probably since I am connection using Spring Data and the default Hikari connection pool.

After spending hours on it, the final solution was found here: [Spring Boot 1.3.5 with Hikari Connection Pool not able to set program name in v$session](https://stackoverflow.com/questions/41129486/spring-boot-1-3-5-with-hikari-connection-pool-not-able-to-set-program-name-in-v)

```
spring:
  datasource:
    hikari:
      data-source-properties:
         v$session.program: AppName

```

Simple, no code changes, and it works!
Depending on your Oracle version, the feature is implemented in the method 
[setEndToEndMetrics](https://docs.oracle.com/database/121/JAJDB/oracle/jdbc/OracleConnection.html#setEndToEndMetrics_java_lang_String____short_) (It has been deprecated since 12.1 in favor of setClientInfo())
or [setClientInfo](https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html?is-external=true#setClientInfo_java_util_Properties_)

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](https://docs.oracle.com/database/121/ARPLS/d_appinf.htm#ARPLS003) (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).