Java Reference
In-Depth Information
Before accessing a database, you must connect to it. With BMP, you must write the program to get a
database connection. In the
MemberBean
class, this is achieved by calling the utility method
getConnection()
. Typically, you get a database connection by following these steps:
1. Specify the database name. In the example, the database name is
"
java:comp/env/jdbc/YachtClubDB
".
2. Obtain the
DataSource
associated with the logical name by searching the Java Naming and
Directory Interface (JNDI).
3. Get the
Connection
from the
DataSource
.
The database's JNDI name is specified in the deployment descriptor during the deployment phase as
shown here:
<entity>
… …
<resource-ref>
<res-ref-name>jdbc/YachtClubDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</entity>
When coding an EJB, you must decide how long it will retain the connection. Generally, you have two
choices: either hold the connection for the lifetime of the bean, or hold it only during each database call.
Your choice determines the method (or methods) in which your bean connects to a database.
With long-term connections, an EJB holds a database connection for its entire lifetime. Because the
bean connects and disconnects just once, its code is slightly easier to write. But there's a trade-off:
other components cannot acquire the connection. This is normally not recommended.
Briefly held connections allow many components to share the same connection. Because the EJB
container manages a pool of database connections, enterprise beans can quickly obtain and release
the connections. In the
MemberBean
class, all methods hold the connection briefly. Before the method
returns, another utility method,
cleanup()
, is called, which returns the connection to the EJB
container's connection pool by calling
con.close()
. In addition, the
cleanup
method closes
resources such as
preparedStatement
.
In almost all the application servers on the market today, the EJB container maintains a pool of
database connections. This pool is transparent to the enterprise beans. When an EJB requests a
connection, the container fetches one from the pool and assigns it to the bean. Because the connection
has already been made, the bean quickly gets a connection. The bean may release the connection after
each database call (as seen in
MemberBean
), since it can rapidly get another connection. Because
such a bean holds the connection for a short time, the same connection can be shared sequentially by
many beans. To further boost the performance of your application, consider using EJB design patterns
and best practices such as value objects (also called data transfer objects sometimes) as described
next.
Using Value Objects for Better Performance
You may have noticed that the
MemberEJB
has
getters
and
setters
for all the EJB instance
variables except the primary key (see
Listing 21-5
). The example is oversimplified for demonstrating the
basic concept of the entity bean. In practice, the member table usually has more columns, such as
street_address
,
city, state, zip_code, country, phone, fax, email,
last_due_payment_date, spouse_name,
and so on. In that case, you may want to consider
different strategies to reduce the network-performance overhead.
Typically, the clients reside in different network nodes from the EJB container where entity beans and
their instances are deployed. It is important to realize that every invocation of an entity bean method is
