What do I do with all these connections, anyway?
In a network-savvy application, you can expect that there will
be lots of connections. WebLogic's products are designed to make
efficient, high-performance connections between your client and
the network resources that it will need. We use different kinds
of connections to accomplish specific tasks.
Because the word "connection" is used to describe many more specific
kinds of links between parts of a network environment, its usage can
sometimes be confusing. This document briefly explains several ways in
which the word "connection" is used in our documentation.
If you are using a database in your WebLogic Express application that uses the multitier WebLogic JDBC driver, here are some explanations of the kinds of connections that you are likely to use in your application.
- Database connection. You are probably familiar with
this kind of connection. It describes the actual link between a
database server and one of its clients. In the WebLogic multitier
framework, the WebLogic Server becomes a "client" of your database server,
and then in turn can provide database services to all of its
T3Clients.
You will probably use one of the jdbcKona two-tier drivers for the
database connection. The jdbcKona two-tier drivers are Type 2 JDBC
drivers that use the client libraries provided by your database vendor
to maintain the connection that is labeled Database connection
in the picture below. You install the client libraries on the host of
the WebLogic Server. That's the only set of client libraries you will need to
maintain and install.
The database connection -- the WebLogic-Server-to-database link
- T3Client connection. The T3Client connection is the
link between a T3Client and WebLogic. The WebLogic JDBC driver uses a
T3Connection to relay database queries to the database via the
WebLogic Server. (There is more information in our whitepaper on Database
Connectivity in WebLogic.)
A T3Client connection may carry lots of different kinds of traffic; it
is "multiplexed," meaning it can handle traffic for WebLogic JDBC, events,
RMI, etc., all at once. A T3Client connection is also bidirectional --
it can handle client-to-server traffic at the same time it is taking
care of server-to-client responses -- and asynchronous, which means
the client can send, send, send several requests without "blocking,"
or waiting for the WebLogic Server to acknowledge them. These attributes
make the T3Client connection an extremely polite and efficient network
citizen.
When you are doing WebLogic JDBC work, you may not even know about the
T3Client connection. You can write your WebLogic JDBC client application so
that the underlying T3Client connection is handled automatically for
you; you do not need to open or close the T3Client connection
explicity. But if you want to exploit other features in the WebLogic Server
framework, you can get to the T3Client's connection very easily.
The T3Connection -- the T3Client-to-WebLogic-Server link
- WebLogic JDBC connection. This is the connection that a
multitier application or applet uses to reach the database via the
JDBC API. A WebLogic JDBC connection is just one kind of traffic that can run
over a T3Client connection, as shown in the illustration below.
You create a WebLogic JDBC connection by calling the getConnection() method in the Driver class. Then you
use the WebLogic JDBC connection to create and execute Statements and examine
ResultSets. (For more on choosing the right JDBC driver for your
particular application, read Choosing
a Java Database Connectivity driver.)
The WebLogic JDBC Connection -- database work with the JDBC API
Of course, to write a database application with WebLogic doesn't
require that you pick out certain kinds of connections for this task
or that. That's all handled transparently for you.
You can see how few lines of Java it takes to write a WebLogic JDBC
application -- just take a look at our demos and examples.
What's a "cached" connection?
Once you have got that WebLogic JDBC connection, you may want to save it so
that your client application can go away, come back, and pick up
exactly where you left off. You can "cache" (save) a WebLogic JDBC connection
in your T3Client's Workspace on the WebLogic Server. Caching a connection
saves all of the information about your use of the database.
So what's a "connection pool"?
A "connection pool" is a collection of WebLogic JDBC connections. You create
a connection pool when you start the WebLogic Server by filling in some
information -- like username, password, and other details -- in the
WebLogic Server's configuration file.
When a T3Client application needs to do database work, your
application can just ask to use a WebLogic JDBC connection from the
connection pool. That saves the time and trouble of creating a WebLogic JDBC
connection each time you need to do database work.
It also gives you some control over how your client applications use
database resources. For example, you might have 100 client
applications that do a bit of database work here and there. It
wouldn't be a very efficient use of resources to create a WebLogic JDBC
connection for each client. Instead, you can create a pool of perhaps
10 or 20 connections -- you can tune that to match your application's
needs -- and each client can request and use a connection from the
pool when necessary, without the overhead of actually creating the
connection time after time. When the client completes its database
work and closes the connection, WebLogic JDBC just returns the connection to
the pool for someone else to use.
Connection pools are one of the convenient features of WebLogic's
WebLogic JDBC that you can take advantage when you understand by creating a
T3Client, connecting to the WebLogic Server, and then setting a couple of
properties. In particular you need to create the T3Client object and
set certain properties to tell WebLogic JDBC to give you a Connection object
that uses one of the Oracle connections from the connection pool.
Links to documentation
More about creating a
WebLogic JDBC connection
More
about cached connections and connection pools
