Until now, whenever I query the database I open a fresh connection to the database. How do I implement the property that once I open the connection I can reuse that?
With this done, please tell me if I could leak the resources.
Basically you need JDBC connection pool, typically implementing DataSource interface. Have a look at dbcp and c3p0. Chances are you container/server already provides an implementation of connection pooling.
When you use a connection pool every time you open a connection you are actually taking one from the pool (or opening if pool is empty). When closing the connection, it is actually returned to the pool. The leak can only occur if you forget the latter. (or forget closing ResultSet, Statement...)
You can (and should) reuse db connections. Connection pooling is one of the techniques for this. A thorough tutorial on connection pooling can be read here : http://java.sun.com/developer/onlineTraining/Programming/JDCBook/conpool.html
Related
I have connections in an application with Tomcat and SQL Server that remain open even though it is explicitly stated that they close java
Is this possible with some configuration in SQL Server?
If your connection came from a connection pool, yes closing the connection will simply return the connection to the pool for another client to use. Connection pooling is more efficient when you have many short-lived connections.
I am working on a basic code to access a query in a database for an alert system. I understand that the database at work (Oracle based) automatically creates a pool of connections and I wanted to know if I connect, execute the query and close the connection every 5-15seconds would the performance drop dramatically and was it the correct way to do it or would I have to leave the connection open until the infinite loop is closed?
I have someone at work telling me that closing the connection would result in the database having to lookup a query each time from scratch but if I leave it open the query will be in a cache somewhere on the database.
ResultSet rs1 = MyStatement.executeQuery(QUERY_1);
while (rs1.next()){
// do something
}
rs1.close();
rs1 = MyStatement.executeQuery(QUERY_2);
while (rs1.next()){
// do something
}
rs1.close();
Oracle can't pool connections, this has to be done on the client side
You aren't closing any connections in the code example you posted
Opening a connection is a rather slow process, so use either a fixed set of connections (typically the set has size one for things like fat client applications) or a connection pool, that pools open connections for reuse. See this question for what might be viable options for connection pools: Connection pooling options with JDBC: DBCP vs C3P0 If you are running on an application server it will probably already provide a connection pooling solution. check the documentation.
closing stuff like the resultset in your code or a connection (not in your code) should be done in a finally block. Doing the closing (and the neccessary exception handling correct is actually rather difficult. Consider using something like the JdbcTemplate of Spring (http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html)
If you aren't using stuff like VPN (virtual private database) Oracle will cache execution plans of statements no matter if they come from the same connection or not. Also data accessed lately is kept in memory to make queries accessing similar data fast. So the performance decrease is really coming from the latency of establishing the connection. There is some overhead on the DB side for creating connections which in theory could affect the performance of the complete database, but it is likely to be irrelevant.
Every time a client connects to the database that connection has to be authenticated. This is obviously an overhead. Furthermore the database listener can only process a limited number of connections at the same time; if the number of simultaneous connection attempts exceeds that threshold they get put into a queue. That is also an overhead.
So the general answer is, yes, opening and closing connections is an expensive operation.
It is always beneficial to be using DB Connection pools especially if you are using a Java EE app server. Also using the connection pool which is out of the box in the Java EE app server is optimal as it will be optimized and performance tested by the App server development team.
Currently I'm creating the DB connection again and again in every JSP/Servlet. I would like to reuse my DB connection in my JSP/Servlet project. How can I achieve this?
The "correct" way to do this is to make use of connection pooling. That way the overhead of creating / closing connections is reduced.
Apart from that there's is nothing wrong with the way you are doing things. Maintaining open connections for too long is generally not a good idea.
To make this less hassle - you can create a utility class which returns a connection from the pool and likewise has a method for returning the connection to the pool.
When I read about the reader functionality of .NET then i came to know that we can open only one reader on one db connection. So it is compulsory for me to use connection pools so my application works without crashing and in this case I also can't apply singleton pattern for my connection. But now when I start to develop the same application in Java then I find that I can do many things with the same connection as well as I can also apply singleton pattern on connection. I just need to create statement object every time.
Now my questions are:
Why does .NET have this limitation on db connection object?
If Java allows this then why should we use connection pools?
No, you can't do arbitrarily many things at once with a single Connection in Java. You might get away with some things, but in general a Connection in Java should only be used for a single thing at a time (by a single thread). That's even more important if transactions come into play, because they are bound to the Connection.
From the sound of it it looks like .NET acts exactly the same, but you were lucky with what you tried in Java.
The correct approach in Java is to use a connection pool and every time you do some business operation, grab a connection from the pool, do you database operations with that connection, then return the connection to the pool (by simply calling .close(), the nice thing is that you don't really need to care if the connection is from a pool or gets re-created each time you request one).
I suspect that in .NET it's very similar.
Because the actual connection to the database is limited in that way. The connection object in Java just opens more database connections when needed. There is a setting that makes the connection object in .NET do the same thing, but I reccomend that you use the default mode, as it gives you better control over the resources.
Because the connection object in Java will get the database connections from the pool. If it would open a new connection to the database, you would see quite a performance difference whenever you use the connection object for more than one reader.
How to handle database connection with multithreaded application. I have developed one application that created more thread. But when i run application it run correctly but after some time application is going to hang....?? what i have to do ..? How to handle Database connection with multithreaded application .?
You'll probably would like to use a connection pool. My recommendation is c3p0.
Database connections and threading need not be completely related.
Where are you fetching your DB connections from? Is it a central data source? Or a custom wrapper over JDBC connection? Or are you fetching it from a DB connection pool? Or are you creating a new connection in each thread?
Connection in the singular? If you only have one connection then you will have to synchronize your threads access to the connection. Better to use a Database connection pool though; almost all database vendors provide a connection pool implementation.