As an experiment in how Hibernate uses a database connection, remove or rename the file hibernate
.properties, or remove the database elements in hibernate.cfg.xml (if you’re using it), in either the stand-alone
or servlet application written in the previous chapter. When you’ve changed the file, execute the
application and attempt an action that accesses the database, such as showing all the CDs. Since our
error handling displays the stack trace, you should get a fairly large trace dump on the console window
where you launched the application. If you’re using the servlet example, you might need to open a log
file to see the errors.
At the top of the stack trace, you should see a message like “user needs to supply connection”. This error
tells you that Hibernate was unable to obtain a connection to any database for more than just a wrong
password. But, in fact, no hibernate.properties file or database elements are available to the application;
as such, the application doesn’t know how to connect to a database. This is obviously bad, because
Hibernate accomplishes most of its work through a database.
The point is, the developers of Hibernate developed the system in a manner that lets you handle a vari-ety
of design situations. In this case, Hibernate can either create its own connection to the underlying
database or use a connection that’s already in place. The examples in Chapter 3 show you how to use
Hibernate connections. If you’re developing an application from scratch, you’ll probably let Hibernate
handle the connection; there aren’t any glaring issues with this type of situation, and there are no perfor-mance
problems. So, why does Hibernate allow user-based connections? Primarily to handle legacy
issues.
Given the constant evolution of software systems, you won’t always be able to rewrite your code. In
some cases, you must refactor live systems. The application has already been written, and database con-nections
are established and available, so why not use them? You need to consider a couple of issues.
The first is connection pooling, which we discuss in detail later in this chapter. If you’re using a previ-ously
established connection, you’ll bypass any connection pooling defined in Hibernate. Second is the
issue of transactions. When you’re using a user-based connection, you can use Hibernate’s transaction
system (discussed in Chapter 10), or the application can handle transactions through the underlying
database using JDBC transactions or through JTA.
Here’s an example of the code for using a previously established connection:
try {
Class.forName("com.mysql.jdbc.Driver").newInstance();
Connection connection = DriverManager.
getConnection("jdbc:mysql://localhost/accounts");
SessionFactory sessionFactory = Configuration.buildSessionFactory();
Session session = sessionFactory.openSession(connection);
} catch (Exception e) {}
.properties, or remove the database elements in hibernate.cfg.xml (if you’re using it), in either the stand-alone
or servlet application written in the previous chapter. When you’ve changed the file, execute the
application and attempt an action that accesses the database, such as showing all the CDs. Since our
error handling displays the stack trace, you should get a fairly large trace dump on the console window
where you launched the application. If you’re using the servlet example, you might need to open a log
file to see the errors.
At the top of the stack trace, you should see a message like “user needs to supply connection”. This error
tells you that Hibernate was unable to obtain a connection to any database for more than just a wrong
password. But, in fact, no hibernate.properties file or database elements are available to the application;
as such, the application doesn’t know how to connect to a database. This is obviously bad, because
Hibernate accomplishes most of its work through a database.
The point is, the developers of Hibernate developed the system in a manner that lets you handle a vari-ety
of design situations. In this case, Hibernate can either create its own connection to the underlying
database or use a connection that’s already in place. The examples in Chapter 3 show you how to use
Hibernate connections. If you’re developing an application from scratch, you’ll probably let Hibernate
handle the connection; there aren’t any glaring issues with this type of situation, and there are no perfor-mance
problems. So, why does Hibernate allow user-based connections? Primarily to handle legacy
issues.
Given the constant evolution of software systems, you won’t always be able to rewrite your code. In
some cases, you must refactor live systems. The application has already been written, and database con-nections
are established and available, so why not use them? You need to consider a couple of issues.
The first is connection pooling, which we discuss in detail later in this chapter. If you’re using a previ-ously
established connection, you’ll bypass any connection pooling defined in Hibernate. Second is the
issue of transactions. When you’re using a user-based connection, you can use Hibernate’s transaction
system (discussed in Chapter 10), or the application can handle transactions through the underlying
database using JDBC transactions or through JTA.
Here’s an example of the code for using a previously established connection:
try {
Class.forName("com.mysql.jdbc.Driver").newInstance();
Connection connection = DriverManager.
getConnection("jdbc:mysql://localhost/accounts");
SessionFactory sessionFactory = Configuration.buildSessionFactory();
Session session = sessionFactory.openSession(connection);
} catch (Exception e) {}