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.
Related
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
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.
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.
Which of these approaches is better: connection pooling or per-thread JDBC connections?
Connection Pooling for sure and almost always.
Creating new database connection is very costly for performance. And different DB engines (depending on licensing or just settings) has different maximum number of connections (sometimes it even 1, usually not more then 50).
The only reason to use Per-Thread connections is if you know that there are certain small number of persistent threads (10 for example). I can't imagine this situation in real world.
Definitely connection pooling. Absolutely no reason to create a new connection for each thread. But, it might make sense to use the same connection for an entire HTTP request for example (especially if you need transactions).
You can easily configure the connection pooling framework to have a min and max number of connections depending on the database that you are using. But before going too high with the max number of connections, try using caching if you have performance issues.
For web apps, connection pooling is generally the right answer for reasons other have already offered.
For most desktop apps running against a database, a connection pool is no good since you need only one connection and having multiple connections consumes resources on the DB server. (Multiply that by the number of users.) Here the choice is between a single persistent connection or else just create the connection on demand. The first leads to faster queries since you don't have the overhead of building up and tearing down the connection. The second is slower but also less demanding on the DB server.
I'm in the process of adding connection pooling to our java app.
The app can work with different rdbmses, and both as a desktop app and as a headless webservice. The basic implementation works fine in desktop mode (rdbms = derby). When running as a webservice (rdbms = mysql), we see that connection pooling is needed to get good concurrent behaviour.
My initial approach was to use dependency injection to decide between a basic DataSource or a connection pooling DataSource at startup time.
The problem in this scenario is that I don't know when to call connection.close(). My understanding is that when using connection pooling, you should close() after each query so the connection object can be recycled. But the current non-pooling implementation tries to hang on to the Connection object as long as possible.
Is there a solution to this problem? Is there a way to recycle a basic connection object? What happens if I don't call connection.close() with a thread pooled connection object?
Or is it simply a bad design to mix these two connection strategies?
If I understand you correctly, essentially you are doing your own pooling implementation by holding on to the connection as long as possible. If this strategy is successful (that is the program is behaving as you describe it), then you have your own pool already. The only thing adding a pool will gain you is to improve the response time when you make a new connection (as you won't really be making one, you will be getting it from the pool), which is apparently not happening all that often.
So, I would cycle back to the assumption underlying this question: Is it in fact the case that your concurrent performance problems are related to database pooling? If you are using transactions in the MySQL and not the Derby, that could be a big cause of concurrency issues, as an example of a different potential cause.
To answer your question directly, use a database pool all the time. They are very little overhead, and of course change the code to release connections quickly (that is, when the request is done, not as long as the user has a screen open, for example) rather than holding on to them forever.