Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,800 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
Author David Gassner explains how to choose a JDBC driver and connect to one or more databases. He also provides detailed instructions on reading, selecting, and updating data; calling stored procedures; managing data via JavaBean classes or with prepared statements; and working with metadata.
- Importing a MySQL database
- Connecting to databases
- Handling JDBC exceptions
- Looping through result sets
- Limiting the number of fetched rows
- Filtering data with prepared statements
- Calling stored procedures
- Inserting, updating, and deleting rows with prepared statements
- Using a persistent database connection
- Committing and rolling back transactions
Skill Level Intermediate
If you have been working through the exercises in this video series, you might have noticed that we're opening a lot of database connections. I'm working in a version of my project called ConnectionManager that has the code for updating a database table. And I'll go to the tables package and open AdminManager.java. The way this application is currently architected every time I call my DBUtil class's getConnection method, I'm opening a new connection, and then I am closing that connection when that method is finished. And if you count up all the times that we are using the get connection method, you'll see that we're opening and closing connections many, many times.
In JDBC this is into great practice, and that's because connections are expensive. They take time, memory, and resources, and so to the extent possible you should minimize the opening and closing of connections by reusing connections. When you work in a Java Enterprise Edition Server environment such as JBoss, the server typically will provide connection pooling. It's a multi-user environment, and so it's vital that multiple users reuse those connections. If you're building your own Java application, though, either as a console application like this or a desktop application, you might need to write your own logic.
In this project, I have provided a bit of code called the ConnectionManager. The ConnectionManager class is a singleton, a class that can only be instantiated once. This is a common design pattern in Java, and it's used whenever you want to make sure that your entire application is using the same object. The ConnectionManager starts with a private static instance of itself, and the name of that field is simply instance. It's initially set to null. It then contains String fields for all the credentials we'll need to connect to databases and a DB type field which is not static.
So it can be changed after this class is instantiated. There is a private field for the connection object, and there's only one, and it's initially set to null. Now here is the code that manages the singleton aspect of the class. The goal of a singleton is to make sure that the entire application can get a reference to it, but it can only be instantiated once from within the class itself. And so we control that with a private constructor. When you mark the one and only constructor method as private, that means that it can only be constructed from within this class.
And then there is a static method called getInstance which checks to see whether the one instance is null, and if it isn't, it instantiates it, and then either way, it returns it. So to get a reference to the one and only ConnectionManager object for the whole application, other parts of the application will call the static method ConnectionManager.getInstance. Let's take look at the rest of the code. There is a public method called setDBType that lets the application decide what type of database we're going to use either MySQL or HSQLDB.
There is a private method called openConnection. We'll only call this method if the connection isn't already open, but it looks exactly the same as it did in our DBUtill class. It checks the database type and then uses the appropriate logic to open either MySQL or HSQLDB. There is public method named getConnection. This method will be called from the one and only instance of the ConnectionManager. It checks to see whether the one and only connection is null, and if it is it opens it and then it returns the reference.
And if the code gets all the way down to this line, it returns the already open reference. Finally, there's a close method. Remember that you should always explicitly close your connections, and using a singleton manager makes no difference. So now the singleton manager is responsible for closing the connection. And in this case, it both closes it and sent it to null so that we can explicitly manage the opening and closing of the connection from anywhere in the application, but only by calling this method. This code is fairly intensive, and if you don't have access to the exercise files, I don't want to make you type it out.
So I have provided this project in the code section of the free exercise files. Now let's see how we can use the ConnectionManager class. I'll go to my main class. The first thing I'll do is set the database type, either HSQLDB or MySQL. I'll place the cursor after the comment. Now I'll get a reference to the ConnectionManager object and set the database type. I'll say ConnectionManager.getInstance, and that gives me the reference to the ConnectionManager, and from there I'll set the database type with DBType.MYSQL.
I'll also add code at the end of the method to ensure that the connection has been closed, and that'll look like this ConnectionManager.getInstance().close. So that's all I have to do from the main class, I set the database type and make sure the connection is closed. Now let's go to the AdminManager class. The AdminManager class is where we have all these calls to the getConnection method, and we're opening and closing the connection over and over. I'm going to change the model for this. I'm going to create my connection as a static field of the AdminManager class.
I'll place the cursor inside the class declaration, but before any of the methods, and I'll declare a private static Connection, and I'll name it conn, as it's been named previously. And I'll get its reference by calling ConnectionManager.getInstance().getConnection. So now the first time any of these static methods are called, this static connection object will get its reference automatically. And I can go through all the rest of the code, and I can comment out or delete all of the other code that's getting the referenced from the DBUtil class.
I'll delete it from the getRow method, I'll keep on scrolling down, and I'll delete it from the Insert method, and also from the Update method. I'll save my changes, and I'll go back to my main class, and I'll run the code again. And because I have system output scattered throughout the application, I'm able to see the order in which things are happening. First, I get the message that the application is starting then the message that the connection is opened. Now, notice I still have input that I have to provide, and if things are working, the connection is still open.
So I went to the number one and a new password, and I get back the message Success. And then I see the message that the connection is being closed, because I get to the code in the main method that calls the close method of the ConnectionManager. So, now I'm using a single connection to my database. I'm saving memory, time, and resources. Again, if you're working in a Java Enterprise Edition Server environment, you'll have a connection pooling architecture that the server provides. But if you're working on a Console or a desktop application, it's up to you to write this code, and this is one possible model that you can try out.
Sign up for a Premium Membership to download courses for Internet-free viewing.
Watch offline with your iOS, Android, or desktop app.Start Your Free Trial
After signing up, download the course here or from the iOS/Android App.