I am developing a simple database project. It has some functions that will be performed on database. I need advice about opening and closing database. Which way is the better below?
When program starts, open database and close when program finishes.
When program starts, when a function is called, open database, and at the end of this function close database.
I am confused for which one is better. In the first case database will be open during the program. In the second case database opening and closing operation will be performed at each function call and also for each function. This will reduce efficiency and also makes code longer.
So which one is the better?
Better is subjective. If you have only a few clients connecting to the database, for short periods of time then perhaps leaving a connection open is the better way to go. However, if you have hundreds of clients needing connections, there are limited number of simultaneous connections that can be supported, keeping the connection open for long periods would be detrimental.
There is an overhead involved in opening and closing connections to the database but you have to balance that against whether the language actually pools the connections for you so it only appears that the connection is closed but if needed will be reused and if not really closed after some period of time, and many other possible criteria.
Better is what meets your needs in the simplest to maintain manner.
Make a separate function like getConnection() which will create and return a Connection object. Put all your code that will create the connection there.
now if in any function you need a database connection call getConnection()
public void myfunction()
{
javax.sql.Connection con = MyConnectionClass.getConnection();
con.open();
// do your business logic here
con.close();
}
There is very little cost to leaving a connection open longer than necessary, so that would favor your idea to open when the program starts and close upon exiting the program.
Related
I am trying to execute multiple queries in a single function using single connection object. I would like to know what is the best practice to close the database connection in a scenario like this. Currently , I close the connection once all the db calls are completed. I am wondering whether I need to close the connection and open a new connection for every db call. Which is better?
You should keep the Connection open as long as possible. Creating a database connection is a (relatively) expensive operation, so you don't want to do it more often that you need to.
To manage the lifetime, you should use the try-with-resources statement assuming you are on at least Java 7:
try (Connection connection = myDataSource.getConnection()) {
// Do your queries here
}
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.
My application-server has a connection to a MySQL database. This connection is open 24/7.
Lets say my internet were to crash, or I were to block the port 3306.
Will JDBC throw an error? And if not, how should I be handling this kind of problem?
The reason I'm asking this is because I've had cases before where the MySQL connection randomly stopped working, but wasn't closed, which caused clients to time out.
You will get a MySQLNonTransientConnectionException or CommunicationsException. Typically, for program safety you either want to:
Open/close connections as necessary
Re-open when connection is closed
I recommend the former personally, especially when the database is user-specified (some mysql setups have a connection timeout).
Edit:
I did seem to forget to mention connection pools, per #ThorbjørnRavnAndersen , but that is also a viable solution. I personally don't do that myself, using an instantiable SQL connection per threaded operation.
Personally, I throw any database calls into try/catch blocks, because there's always the potential for issues to arise. You'll want to set some default values in the catch block, and if it happens to land on these defaults for whatever reason, display the end user some sort of (ideally pretty) error message.
Running a SQL query isn't always guaranteed to pull back any sort of results either...any number of things could go wrong - the server could be down, the connection could be so saturated that it's not able to pull the results in a timely manner, it could be sitting in the dead center of a backup of sorts too....These things have to always be accounted for, that's why I recommend doing it the way described above.
Lastly, to answer your question, yes, JDBC will in fact throw an error - under any of these circumstances.
When an external event occurs (incoming measurement data) an event handler in my Java code is being called. The data should be written to a MySQL database. Due to the high frequency of these calls (>1000 per sec) I'd like to handle the inserts efficiently. Unfortunately I'm not a professional developer and an idiot with databases.
Neglecting the efficiency aspect my code would look roughly like this:
public class X {
public void eventHandler(data) {
connection = DriverManager.getConnection()
statement = connection.prepareStatement("insert …")
statement.setString(1, data)
statement.executeUpdate()
statement.close()
connection.close()
}
}
My understanding is that by calling addBatch() and executeBatch() on statement I could limit the physical disk access to let's say every 1000th insert. However as you can see in my code sketch above the statement object is newly instantiated with every call of eventHandler(). Therefore my impression is that the batch mechanism won't be helpful in this context. Same for turning off auto-commit and then calling commit() on the connection object since that one is closed after every insert.
I could turn connection and statement from local variables into class members and reuse them during the whole runtime of the program. But wouldn't it be bad style to keep the database connection open at all time?
A solution would be to buffer the data manually and then write to the database only after collecting a proper batch. But so far I still hope that you smart guys will tell me how to let the database do the buffering for me.
I could turn connection and statement from local variables into class
members and reuse them during the whole runtime of the program. But
wouldn't it be bad style to keep the database connection open at all
time?
Considering that most (database-)connection pools are usually configured to keep at least one or more connections open at all times, I wouldn't call it "bad style". This is to avoid the overhead of starting a new connection on each database operation (unless necessary, if all the already opened connections are in use and the pool allows for more).
I'd probably go with some form of batching in this case (but of course I don't know all your requirements/environment etc). If the data doesn't need to be immediately available somewhere else, you could build some form of a job queue for writing the data, push the incoming data there and let other thread(s) take care of writing it to database in N size batches. Take a look what classes are available in the java.util.concurrent-package.
I would suggest you use a LinkedList<> to buffer the data(like a queue), then store the data into the dbms as and when required in a separate thread, executed at regular intervals(maybe every 2 seconds?)
See how to construct a queue using linkedlist in java
I would like to perform updates to a MySQL database using two separate classes (that do different things) -- one doing so every 10 seconds, and the second every minute. I have a few gaps in my Java knowledge and I'm wondering what the best way to achieve it is.
Importantly, if connectivity to the database is lost, I need reconnection attempts to occur indefinitely, and I'm guessing the use of Prepared Statements will make queries more efficient. Should the connection to the database be left open all the time or closed between the updates being run? Maybe I also need to think about clearing objects/resources out of memory if the class instances are going to be run indefinitely.
Answer to your first question "how to run java class at some specific interval?"
You can use quartz triggers to run java class at time interval.
Second Question: "what if conn is lost?"
Check in class that runs at time interval for connection if its open then dont attempt to connect and if lost then first connect to db and then update the db.
Third question: "Should the connection left open every time?"
If you wanna do update with very small time gap then i think yes you should keep it open.but not sure about it. May be you should try it keeping open.
I would keep the database connection open but do noty try to manage the open connection yourself. Use a connection pooling library like Apache DBCP. It allows to specify a validationQuery which technically a very simple SELECT request that is executed before the actual statement for validating if the connection is still alive. In my application this works rock solid (one app that runs 24/7; queries about every minute).