We have lots of micro services which need connection to DB. Oracle and PostgreSQL can handle just limited amount of connections. PostgreSQL solve this situation with PgBouncer so application connect to this URL which handle connection pooling. Is there something similar in Oracle ? What I found is oracle UCP but I think this is still pooling in application not in DB.
If your clients drivers are not too old (pre oracle-12) you can use Oracles Database Resident Connection Pooling.
See https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/database-resident-connection-pooling.html#GUID-D4F9DBD7-7DC6-4233-B831-933809173E39
Database Resident Connection Pooling
Database Resident Connection Pool (DRCP) is a connection pool in the server that is shared across many clients. You should use DRCP in connection pools where the number of active connections is fairly less than the number of open connections.
Especially database administrators will love this because they can have a good control on the hits on the database.
I am working with ADO connection with C++ where I connect to DataBase fetch records and close connection. ,
My porblem is we have to connect, fetch records and close connection every time for single user and we have more than one million users.
Is there any way that we can keep connection alive or have some pooling mechanism running background so we done have to connect always ?
I searched for connection pooling with C++ , but could not find anything
Thanks in advance
Connections are pooled by default with ADO classic (which uses OLEDB services for connection pooling). The cost of the physical network connection is incurred only during the initial open. As long as you properly close/dispose connections, the subsequent overhead is minimal without coding to handle persistent connections.
We have several web applications using my-batis as a connection pool on the web server. We are using the Oracle 12c database. Now we are adding a new application X which uses individual connections for every request and is very inefficient. We would like to enable the Oracle DRCP connection pool and have application X use it without affecting the previously existing apps that have a connection pool. Our DBA informed me that it looks like all the applications will have to use the Oracle DRCP connection pool if it is enabled, meaning we will have to reconfigure the connection method in all of our applications for this application X.
Does anyone know if this is the case, or can you have the Oracle DRCP connection pool running without affecting our middle tier connection pools?
Oracle DRCP does not interfere with any other connections methods you are currently using, it only adds another option to connect to the DRCP connection pool.
This was verified when the DBA decided to give it a try and turn on the DRCP connection pool in our Oracle database. We were able to connect to the new DRCP connection pool with our new application X and our other applications continued to work without any modification necessary.
Communicate with the database in java, we often follow these steps:
load a driver
get a connection
create a Statement or PreparedStatement
get the ResultSet
close the connection
I am confused that we should close connection, all say that create a connection is expensive, so why we can't do like this:
static
{
try
{
connection = DriverManager.getConnection(connectorURL,
user, password);
} catch (SQLException e)
{
e.printStackTrace();
}
}
We just create a connection as a singleton, and use it everywhere. Couldn't it? If I use it like this, what will happen?
And if I don't close the connection, what will happen?
Also, we will use a connection pool, it will create some connections in the pool, and we get the connection from the pool, the connection in the pool also don't close, why if we don't use pool, we need follow the steps and close the connection if we don't use?
It's so confused and I don't know the what's the principle. Please help me. Thanks.
If we don't close the connection, it will lead to connection memory leakage. Until application server/web server is shut down, connection will remain active, even if the user logs out.
There are additional reasons. Suppose database server has 10 connections available and 10 clients request for the connection. If the database sever grants all of them, and after their usage they are not closed, the database server would not be able to provide any other connection for another request. For that reason we need to close them - it is mandatory.
Furthermore, it might lead to some mischievous activities regarding the integrity of the database.
We just create a connection as a singleton, and use it everywhere. Couldn't it? If I use it like this, what will happen?
In this case, you will have only a single database connection. If database query is having a longer execution time, then other requests for that connection object will have to wait. So, this is not a recommended approach.
And if I don't close the connection, what will happen?
By closing the connection, objects of Statement and ResultSet will be closed automatically. The close() method is used to close the connection. If you forget to do so, it will lead your app to connection memory leak. For Example: Imagine that your app has 10 database connections and 10 users are active at the same time. Later on, 3 users log out of the app, but because you didn't implement connection closing mechanism, those 3 connections remain active, and as a result, your app will not provide any other connection to some other user. Also, increased number of opened connections, in database server, slows down the app. So, release the Connection object's database and JDBC resources immediately, instead of waiting for them to be automatically released.
Also, we will use a connection pool, it will create some connections in the pool, and we get the connection from the pool, the connection in the pool also don't close, why if we don't use pool, we need follow the steps and close the connection if we don't use?
Connection pooling means that connections are reused rather than created each time a connection is requested.
This source says, that: "If the system provides connection pooling, the lookup returns a connection from the pool if one is available. If the system does not provide connection pooling or if there are no available connections in the pool, the lookup creates a new connection. The application benefits from connection reuse without requiring any code changes. Reused connections from the pool behave the same way as newly created physical connections. The application makes a connection to the database and data access works in the usual way. When the application has finished its work with the connection, the application explicitly closes the connection.
The closing event on a pooled connection signals the pooling module to place the connection back in the connection pool for future reuse."
Your application borrows a connection from the pool, uses it, then returns it to the pool by closing it. A connection in the free pool for a long period of time is not considered an issue.
I have a Web Application that use Hibernate 3.0. When I restart my database server, is it always necessary to restart jboss server?
Can I reconnect to database without restart jboss server?
Depends on the pool configuration.
If you enable the "validate connection" checking, by passing a SQL to be executed before a connection is handled to the caller, your application will not get invalid connections. Meaning that the connection will be thrown out and a new one will be acquired in case the connection is broken. The price you pay for this, of course, is that you are doing a round-trip to the server.
But usually, you could leave this out and let the Exception sorter handle the case. In case JDBC problems are thrown by the Driver, this "Sorter" will analyse them and determine if the connection can be returned to the pool or not. I'm not sure about the MySQL implementation of the Exception Sorter, so, it might be worth trying. If it doesn't helps, you can always extend the existing sorter and add your logic to it.