We Keep Coding

Spring JDBC Hikari constantly logon logoffs in Oracle Database

I am using spring boot hikari db pool to connect to an Oracle database (19C).
Our properties are as below:
spring.datasource.app.hikari.type=com.zaxxer.hikari.HikariDataSource
spring.datasource.app.hikari.minimumIdle=5
spring.datasource.app.hikari.maximumPoolSize=10
spring.datasource.app.hikari.idleTimeout=600000
spring.datasource.app.hikari.connectionTimeout=180000
spring.datasource.app.hikari.max-lifetime=60000
Our Database's AUD table is filling up due to constant logon logoff actions getting registered from the services every second.
I used solution from below question (to decrease minimumIdle and increase idleTimeout for long idle times), but it did not resolve the issue.
spring jdbc hikari connection pool - constantly logs on and off to database
Can somebody help in this case. Thanks in advance.

If you have not override datasource with different property name for hikaricp then use below properties
spring.datasource.type=com.zaxxer.hikari.HikariDataSource
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.connection-timeout=180000
spring.datasource.hikari.max-lifetime=60000

how to get the size of hibernate connection pool?

I have an app that is written in java spring.
It uses hibernate to handle connections to postgres DB.
I want to get the size of the connection pool, but it isn't defined on the app's hibernate configurations.
So I guess it uses hibernate default size, which is 1?
That sounds very low to me.
How can I be sure what is the size of connection pool?
I read that it is recommended to use third party manager for this, but I don't think it's in used also.

Pooling PreparedStatement on Tomcat with MySQL

When using Tomcat with MySQL, what is the relationship between poolPreparedStatements setting in Tomcat DataSource configuration (I believe coming from DBCP) and Connector/J cachePrepStmts setting? What's the optimal configuration?

poolPreparedStatements is a setting for the Tomcat JDBC connection pool and cachePrepStmts is a setting for Connector/J to tell MySQL to cache prepared statements. Two completely different things. cachePrepStmts is a per connection setting, but Connector/J doesn't concern itself with whether it's connecting to a database connection pool or to MySQL directly, yet cachePrepStmts works at it's best with persistent connections (e.g. connection pools). To use cachePrepStmts with a connection pool is the optimal configuration. Using poolPreparedStatements in Tomcat is to open a can of memory management worms (check out the Tomcat docs for this setting and you'll see). Really, it's best to let MySQL cache the prepared statements and let Tomcat pool the connections and not try to have one do the other's job.

Context specific usernames for connections on a Java EE Datasource (JBoss 5.1)

We have an application that needs to access a database that is owned by a different team.
That database has security inside the database (triggers, table permissions, etc) and so we need to establish a connection to the database using the same username/password that connected to our EJB.
We're running on JBoss 5.1. Standard Java EE solutions are preferred, but JBoss specific answers will do.
At the moment our solution is
Create a datasource in JBoss with no user-id password
Require the client to pass their username/password into the EJB (the EJB is a stateful session bean (SFSB), and remembers the username/password)
The session bean creates a new connection using DataSource.getConnection(String, String)
The connection is "created" from the datasource at the start of each request (The datasource implementation might reuse an existing connection)
The main problem we have is connection pooling.
The JBoss connection pool doesn't manage separate pools for each username - they're all thrown into 1 big pool, and the username is checked after the object is retrieved from the pool (inside InternalManagedConnectionPool).
If the usernames don't match, then the connection is removed from the pool & destroyed.
This means that as soon as we have 2 users, there's a 50% chance that any connection that is put into the pool will be destroyed when it is next accessed. And as we increase the number of users, those odds get a lot worse.
We can't simply create 1 connection in the SFSB and retain it because JBoss is too smart for us, and it detects that we've left a connection open and automatically returns it to the pool for us, so the next request to the SFSB will fail with a "not associated" connection.
It would also be nice if we could simply get JBoss to create a connection as "the currently logged in user", but the solution we have is bearable.
My googling has failed to find any recommended patterns for doing this sort of thing. Everyone seems to assume that you want your datasource to use a single user for all connections (which is nice when it's possible, but I can't do that in this case)
The only solutions I can some up with are
Don't use a container provided datasource. Put the JDBC URL into a configuration value somewhere and create connections myself (possibly with the help of spring)
Bind a different Datasource implementation (possibly a custom one) into JNDI
Has anyone got any better solutions? Or pointers to recommended practices in this area?
(The database is Sybase ASE 15, but I doubt that makes any difference to the solution)

A bit more reading of the documentation has led me to what appears to be the solution.
Adding
<application-managed-security/>
into my datasource file seems to have fixed the problem of pooling the connections.
I'm not sure how I missed that the first time around.

Oracle connection/query timeout

Is it possible to specify connection/query timeout for the Oracle database queries? Either on Oracle side or in Oracle's JDBC driver (10.2.0.4)? So, that Java client just got an error back after, let's say, 2 minutes instead of waiting until Oracle finishes executing the query?

If you are executing the query in the context of a transaction, the transaction timeout value of the JTA transaction monitor will be the determinant to query timeout. The configuration for this depends from one application server to another.
At an individual query level (in the absence of a JTA transaction monitor), the setQueryTimeout method can be used to set the timeout on the execution of a Statement/PreparedStatement/CallableStatement object.
Update
setQueryTimeout is not to be relied on, although it works (atleast from a J2SE client). It works via the JDBC driver performing a full round-trip to the Oracle database server. Then, it is upto the database to halt execution of the query. Don't rely on it for time critical applications.

Have a look at Oracle profiles. This allows you to specify several limits at the database level. One of them is a maximum CPU time per query.
If you have queries running for more than 2 minutes on a regular basis you might want to do some tuning of your queries first.

According to http://www.javamonamour.org/2012/09/oraclenetconnecttimeout.html
oracle.net.READ_TIMEOUT for jdbc versions < 10.1.0.5 oracle.jdbc.ReadTimeout for jdbc versions >=10.1.0.5
So if you are using a JDBC driver version 10.1.0.5 or higher, then oracle.jdbc.ReadTimeout is the correct property.

Setting oracle.jdbc.ReadTimeout helped to timeout the jdbc calls. I have used it in a production spring boot app by specifying datasource properties as below
spring.datasource.hikari.connection-timeout=1000
spring.datasource.hikari.dataSourceProperties=oracle.jdbc.ReadTimeout=2000
Note: Earlier this app was using tomcat connection pool and after setting the above properties for the same, timeouts were happening but the pool was not able to handle the closed connection objects efficiently. Therefore, I switched to hikariCP and got lot better results. I have made a video simulating the slow jdbc calls which compares the results with tomcat and hikari connection pools while using the ReadTimeout property.