c This is the call to the context constructor. The context is part of the JNDI specifi-
cation and represents a group of named-resource pairs. Our named resource will
be the data source.
d Here we use the context, created in steps 1 and 2, to obtain a data source. The data
source is the construct that manages our connection pool. If there is no data source
in the context, the context lookup will fail, and we'll create a factory object and
data source within the catch statement block beginning at step 5.
e In this step, we use the data source that was obtained from the context to get a
connection. We'll get an active connection from a pool if one exists; otherwise,
we'll create one. This connection is then returned to the invoker of this method.
f We are inside the catch loop, which probably means that we've failed to get the data
source. We assume that we don't yet have an instance of the data source factory.
g We create a data source factory.
h The Attributes type is a WebSphere type that encapsulates the attributes to
DataSourceFactory.createJDBCDataSource () per the Java specification. Here,
we create the JDBC data source that will be used to pool our connections.
i We bind the resource. We now have a named resource that we can find through
the context that we created in steps 1 and 2.
This seems like a significant amount of overhead, but notice that we have no
remote communications and no loops. This is a small fraction of the overhead
we'd normally experience for each database connection. Using the connection
is similar, but not identical, to our previous example.
We now have a method to obtain a pooled connection. This method will be
called from our command beans, within the initialize() methods. We'll
assume that we've broken out the driver, URL , user ID , and password as sepa-
rate attributes with getters and setters. This is how the method is used:
connection = getPooledConnection(getDriver(),
connBean = new DatabaseConnection(connection);