Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss

JavaSercer Pages The DataSourceWrapper class implements the DataSource interface, so that it can be used in place of a pure JDBC 2.0 connection pool implementation. The constructor creates an instance of the real connection pool class, using the provided JDBC driver, URL, user and password information. Besides the constructor, the two most interesting methods are getConnection( ) and returnConnection( ). The pool client application calls the getConnection( ) method, and the DataSourceWrapper relays the call to the connection pool class. It then wraps the Connection object it receives in a ConnectionWrapper object and returns it to the client application. As described earlier, the ConnectionWrapper object calls the return-Connection( ) method when the pool client calls close( ) on the ConnectionWrapper object. The returnConnection( ) method hands over the Connection to the real connection pool so it can be returned to the pool. All other DataSource interface methods are implemented to throw an SQLException. If you use the wrapper classes presented here to wrap a more sophisticated connection pool, you may be able to relay some of these method calls to the real connection pool instead. 17.1.3 Making a Connection Pool Available to Application Components Through a DataSource object, the servlets and JSP pages in an application can get the Connection they need to access a database. What’s missing is how they get access to the DataSource . I touched on this in Chapter 14, but let’s recap and add a few details. The place for resources that all components in an application need access to is the application scope, corresponding to ServletContext attributes in the servlet world. The current versions of the servlet and JSP specifications, 2.2 and 1.1 respectively, do not provide a specific mechanism for automatic creation and release of application scope objects when the application starts and stops (but this is being discussed as a feature for future versions of the specifications). A regular servlet can, however, fill this need nicely.8 As described in Chapter 14, the container can be configured to load and initialize a servlet when the application starts. Such a servlet can create objects and make them available to other application components in its init( ) method before any user requests are received. The servlet is also informed when the application is shut down by a call to its destroy( ) method, allowing it to release all shared objects. Finally, a servlet can read configuration data, defined as servlet initialization parameters, so that it can work in different settings. In this section, we look at how all of this can be used to make a DataSource object available to all components of an application. The servlet used to manage the shared DataSource can be defined like this in the application’s WEBINF/ web.xml file: appInit com.mycompany.AppInitServlet

jdbcDriverClassName sun.jdbc.odbc.JdbcOdbcDriver

jdbcURL jdbc:odbc:example

dbUserName foo

dbUserPassword bar 1 … 8 Theoretically, a web container is allowed to unload a servlet at any time, for instance to preserve memory. This could cause the shared resources to be removed while other parts of the application are still active and need access to them. In practice, though, none of the major web containers unloads a servlet before the application as such is shut down. page 240

Hint: This post is supported by Gama web hosting php services