My program is using connection as parameter.
For example, I define connection parameter in my main class then I pass the connection as parameter when I call method from another class. would it make any difference to the program performance if i replace with connection pool?
You absolutely do not worry about performance on such a "naive" level. You only focus on performance when you see performance issues (note: of course, you avoid to do outright stupid things). And when you see real performance problems, you do profiling in order to understand the real problems.
In other words: you should focus on creating a good SOLID OO design instead. And (as far as that is possible without seeing any code of yours) from that point of view, you definitely stick with passing in a Connection.
You see, you have some "client" code that is supposed to do "something" with that connection. So the responsibility of that client is exactly that: to use that connection to manipulate whatever that Connection connects to. It should not be the responsibility to also "establish" that connection.
Meaning: one piece of client code is responsible for fetching a Connection from the Connection Pool; and some other client code is responsible for using that Connection to do whatever. You should not mix those two aspects. Otherwise you reduce your options to re-use the individual functionalities; and you couple elements, that simple do not need to be coupled.
Related
I have the following scenario:
MethodA() calls MethodB()
MethodB() calls MethodC()
All methods have to execute some query to DB. So, to do this I create a connection object and pass it along the chain of methods to reuse the connection object.
Assumption here is that connection pooling is not being employed.
Now my question is, should only a single connection be opened and reused and be closed at the starting point (in the above example, the connection will be opened and closed in MethodA) ? or should I create a separate connection for each method?
Reusing the connection seems better, but then I will have to keep the connection open till the control comes back to MethodA().
I have read that reusing the connection is better as they are expensive to create. But then I have also read that its better to close the connection as soon as possible, i.e., once you are done with the query call.
Which approach is better and why?
It sounds like you are only querying the DB and not updating or inserting. If that is the case then you avoid many of the transactional semantics in such a nested procedure call.
If that is true, then simply connect once, do all your querying and close the connection. While usage of a connection pool is somewhat orthogonal to your question - use one if you can. They greatly simplify your code because you can have the pool automatically test the connection before it gives one to you. It will auto-create a new connection if the connection was lost (let's say because the DB was bounced).
Finally, you want to minimize the number of times you create a DB Connection BECAUSE it is expensive. However, this is often non-trivial. Databases themselves only support a maximum number of connections. If there are many clients, then you would need to take this into consideration. If you have the trivial case - one database and your program is the only one making connections, then open the connection and leave it open for the duration of the program. This would require you to validate it, so using a DB Pool, size of 1, avoids that.
I think somebody is confusing their patterns. I've got one guy telling me to use thread pooling and another telling me to use a ConnectionFactory (granted the second guy is not a software engineer, but a very knowledgeable system architect). I'm going to use thread pooling, so we can keep the number of connections to a reasonable number of threads. I've looked all over the internet and I cannot see anywhere where anyone is using both together. I'm thinking about dumping the ConnectionFactory, because it seems redundant at the very least and I just cannot see why or how to use both.
Just curious to see if somebody more knowledgeable than me has ever seen the two used together and can enlighten me as to why.
Also, each connection has to have its own instance of several other classes and we are using a pub-sub architecture. I need to make sure that the subscribers are NOT getting a published message that belongs to another connection. Can I manage that with a ConnectionFactory or do I absolutely need to use a new thread to ensure separation between connection processes?
Just looking for some direction here.
Thank you.
In general Factory pattern is how to create an object. So ConnectionFactory pattern abstracts the way Conncetion is created.
Thread pool abstracts the way threads are managed, i.e. the main things are: when they are started, how many of threads are runnable, their scheduling, their stopping - not creation process!
You can use both this patterns. Your pool can use factory to properly create thread or connection objects.
well, I've been thinking of making database requests a little faster by keeping the connection to the database open as long as the object is being used. So I was thinking of opening the connection in the constructor of that class.
Now the question is, how can I close the connection after I stopped using? I have to call close() somewhere, don't I?
I've been reading about the finalize() method, but people seemed to be skeptical about usage of this method anywhere at all. I'd expect it to have something like a destructor, but Java doesn't have that, so?
So could anyone provide me with a solution? Thanks in advance.
I would suggest that you rather implement database connection pooling if the application would allow it. With connection pooling a pool of connections would be created and stay connected to the database. Your application would then grab a open/unused connection from the pool use it and return it to the pool.
This would allow you to acquire connections faster and you won't have to modify your classes too much. Database connection pooling is a great technique if you need to scale your application.
The other benefit is that your database connection pool will be managed by some sort of driver which will take care of opening connections, keeping them open, growing the pool if required and also shrinking the pool when extra connections are not used for a certain amount of time. This would be similar to the code you are trying to implement in the constructor and finalization methods.
Generally speaking you aqquire a database connection only when needed and release it as soon as possible.
I would recommend to make your class an implementor of java.io.Closeable. According to this interface you will have to implement void close() throws IOException, which all clients of the class will call, because it's a good practice to close Closeable classes after use.
I'm writing a DB connection pool in Java. It's just a class that holds a bunch of connections and gives them out.
Do I need some kind of destructor method so that the DB connections will be closed when an instance of my class goes out of scope?
Edit:
This is for learning purposes only. I would definitely use a reliable, open source connection pool in production use. I really just want to understand the memory management implications.
If you are trying to do this for learning purposes then what you are doing is fine. Download the source code for one of the below mentioned libraries and browse through their code. That would help you in understanding how are they handling the life-cycle of a connection.
But if you want to use it as part of a production application then I'd highly recommend to use one of the below
BoneCP
c3p0
Just off the top of my head, say you have an object, your key. Implement a unique identity for your key. hashCode() is a good place to start. When you create your object, place the object in a WeakReference and associate it to a ReferenceQueue. Now use the hashCode as the key to a Map<int, Connection>. When your object goes out of scope, go to the ReferenceQueue to retrieve the object, use the hashCode to get the Connection from the Map and close it.
See tutorial on references here
The correct way to do it is to wrap the connection instance in your own class which implements java.sql.Connection, then give that "Connection" out through the pool. You will be forced to implement all of the methods which you can happily pass on to the "real" connection. Except for one - close(). In this method you should return the connection to the pool without closing it.
You can't have an object returned to the pool by just letting it go out of scope. You can put something in finalize() which returns it to the pool, but doing this is dangerous. Finalize() only runs once for any object, so if you put something in there to "catch" the object and prevent it from being gc'd, the finalize() will never be called on it again.
I have a Java program consisting of about 15 methods. And, these methods get invoked very frequently during the exeuction of the program. At the moment, I am creating a new connection in every method and invoking statements on them (Database is setup on another machine on the network).
What I would like to know is: Should I create only one connection in the main method and pass it as an argument to all the methods that require a connection object since it would significantly reduce the number of connections object in the program, instead of creating and closing connections very frequently in every method.
I suspect I am not using the resources very efficiently with the current design, and there is a lot of scope for improvement, considering that this program might grow a lot in the future.
Yes, you should consider re-using connections rather than creating a new one each time. The usual procedure is:
make some guess as to how many simultaneous connections your database can sensibly handle (e.g. start with 2 or 3 per CPU on the database machine until you find out that this is too few or too many-- it'll tend to depend on how disk-bound your queries are)
create a pool of this many connections: essentially a class that you can ask for "the next free connection" at the beginning of each method and then "pass back" to the pool at the end of each method
your getFreeConnection() method needs to return a free connection if one is available, else either (1) create a new one, up to the maximum number of connections you've decided to permit, or (2) if the maximum are already created, wait for one to become free
I'd recommend the Semaphore class to manage the connections; I actually have a short article on my web site on managing a resource pool with a Semaphore with an example I think you could adapt to your purpose
A couple of practical considerations:
For optimum performance, you need to be careful not to "hog" a connection while you're not actually using it to run a query. If you take a connection from the pool once and then pass it to various methods, you need to make sure you're not accidentally doing this.
Don't forget to return your connections to the pool! (try/finally is your friend here...)
On many systems, you can't keep connections open 'forever': the O/S will close them after some maximum time. So in your 'return a connection to the pool' method, you'll need to think about 'retiring' connections that have been around for a long time (build in some mechanism for remembering, e.g. by having a wrapper object around an actual JDBC Connection object that you can use to store metrics such as this)
You may want to consider using prepared statements.
Over time, you'll probably need to tweak the connection pool size
You can either pass in the connection or better yet use something like Jakarta Database Connection Pooling.
http://commons.apache.org/dbcp/
You should use a connection pool for that.
That way you could ask for the connection and release it when you are finish with it and return it to the pool
If another thread wants a new connection and that one is in use, a new one could be created. If no other thread is using a connection the same could be re-used.
This way you can leave your app somehow the way it is ( and not passing the connection all around ) and still use the resources properly.
Unfortunately first class ConnectionPools are not very easy to use in standalone applications ( they are the default in application servers ) Probably a microcontainer ( such as Sping ) or a good framework ( such as Hibernate ) could let you use one.
They are no too hard to code one from the scratch though.
:)
This google search will help you to find more about how to use one.
Skim through
Many JDBC drivers do connection pooling for you, so there is little advantage doing additional pooling in this case. I suggest you check the documentation for you JDBC driver.
Another approach to connection pools is to
Have one connection for all database access with synchronised access. This doesn't allow concurrency but is very simple.
Store the connections in a ThreadLocal variable (override initialValue()) This works well if there is a small fixed number of threads.
Otherwise, I would suggest using a connection pool.
If your application is single-threaded, or does all its database operations from a single thread, it's ok to use a single connection. Assuming you don't need multiple connections for any other reason, this would be by far the simplest implementation.
Depending on your driver, it may also be feasible to share a connection between threads - this would be ok too, if you trust your driver not to lie about its thread-safety. See your driver documentation for more info.
Typically the objects below "Connection" cannot safely be used from multiple threads, so it's generally not advisable to share ResultSet, Statement objects etc between threads - by far the best policy is to use them in the same thread which created them; this is normally easy because those objects are not generally kept for too long.