The JDBCGlobalBroker Kit 2.0.0:

The JDBCGlobalBroker kit contains everything necessary to create global database connection pools in a Java Servlet environment. It requires DbConnectionBroker.class which is included in this kit.

The Kit includes:

1.) HttpServletJXGB.java

2.) HttpServletJXGB.class

3.) DbConnectionBroker.class

4.) GlobalBrokerExample1.java

5.) JXGBconfig.data

6.) Readme.txt

----------> What is JDBCGlobalBroker?

JDBCGlobalBroker provides a global database connection pool for any number of servlets running in a java VM through inheritance:

It Creates a global JDBC connection pool which is accessible (shared) among one or more servlets. This provides all the benefits of a 3-Tier architecture for database connectivity in a very simple and effective 2-Tier class. JDBCGlobalBroker (with DbConnectionBroker) gives you the option of choosing global, local, or both types of connection pools in your Servlets with one consistent set of methods.

JDBCGlobalBroker supports all the methods of DbConnectionBroker and adds a new construction method which uses a global file to specify connection parameters. (See the example file JGBconfig.dat in this distribution)

The global pool is implemented through the simple mechanism of inheritance. The HttpServlet class is extended to the HttpServletJXGB class.

----------> Why would I want to use a global connection pool?

For example, if you had 40 servlets and a 5 user license for your database, you might want to set up a global broker with a max pool size of 5. That way, all 40 servlets would share the 5 connections in Round-Robin order. You could even share the 5 connections among multiple applications running on your server.

----------> Why would I want to use a local connection pool?

If you had 3 complex Servlets and wanted to track their individual use/load on the database, you could set up 3 local brokers (one inside each Servlet) each with its own unique login/password combination. You could then track the individual performance and system requirements of each Servlet using the unique database IDs and your database system's GUI tools.

Or, you may want to use local connection pools when you are developing new Servlets in a production system and don't want development bugs to hang up your main broker. You would develop the Servlet with a local broker and simply switch it over to the global broker once it is ready for production.

----------> Don't I have to run a separate Server process with a listener to

handle connections for more than one Servlet?

Previous to Java Servlets, the database connectivity problem had been addressed with complex 3-Tier designs involving independent server processes, connection listeners, sockets, etc. With Java Servlets, we may now eschew this unnecessary complexity for the power and simplicity of a modern, threaded language. We no longer need to wait for programmers to produce monolithic, proprietary solutions for the issues of database connectivity. It's all built into Java!

As the Good Witch said to Dorothy, "you've had the power all the time..."

Try it out by downloading the kit from http://javaexchange.com

-Marc Mnich