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

JavaSercer Pages 17.2.1 The SQLCommandBean and Value Classes

JavaSercer Pages 17.2.1 The SQLCommandBean and Value Classes The SQLCommandBean has three write-only properties. Example 17.3 shows the beginning of the class file with the setter methods. Example 17.3. SQLCommandBean Property Setter Methods package com.ora.jsp.sql; import java.util.*; import java.sql.*; import com.ora.jsp.sql.value.*; public class SQLCommandBean { private Connection conn; private String sqlValue; private Vector values; private boolean isExceptionThrown = false; public void setConnection(Connection conn) { this.conn = conn; } public void setSqlValue(String sqlValue) { this.sqlValue = sqlValue; } public void setValues(Vector values) { this.values = values; } … The connection property holds the Connection to use, and the sqlValue property is set to the SQL statement to execute, with question marks as placeholders for variable values, if any. The placeholders are then replaced with the values defined by the values property, a Vector with one com.ora.jsp.sql.Value object per placeholder. Before we look at the other SQLCommandBean methods, let’s look at the Value class. The Value class is an abstract class used as a superclass for classes representing specific Java types, as shown in Figure 17.3. It contains default implementations of methods for getting the specific type of value a subclass represents. Example 17.4 shows two of the methods. Example 17.4. Two Value Class Methods public abstract class Value { public BigDecimal getBigDecimal( ) throws UnsupportedConversionException { throw new UnsupportedConversionException( “No conversion to BigDecimal”); } public boolean getBoolean( ) throws UnsupportedConversionException { throw new UnsupportedConversionException( “No conversion to boolean”); } … The default implementation for each method simply throws a com.ora.jsp.sql.UnsupportedConversionException . Each subclass implements the method that returns the value of the type it represents, as well as the getString( ) method. The getString( ) method returns the value converted to a String. Example 17.5 shows the com.ora.jsp.sql.value.IntValue subclass. Example 17.5. The IntValue Class package com.ora.jsp.sql.value; import com.ora.jsp.sql.Value; public class IntValue extends Value { private int value; public IntValue(int value) { this.value = value; } page 243

Hint: If you are looking for very good and affordable webspace to host and run your java hosting application check Sandzak.com java web hosting provider

Cms hosting - JavaSercer Pages The initialization servlet should also clean

JavaSercer Pages The initialization servlet should also clean up when the application is shut down. The web container calls the destroy( ) method: public void destroy( ) { getServletContext( ).removeAttribute(”exampleDS”); } Most connection pools used in production provide a method that should be called at shutdown to let it close all connections. If you use such a pool, you need to call this method in the servlet’s destroy( ) method as well. The example pool used here doesn’t provide a shutdown method. 17.2 Using a Generic Database Bean All the database custom action tag handler classes described later in this chapter are based on a generic database bean named com.ora.jsp.sql.SQLCommandBean . This bean uses a number of other classes. Figure 17.3 shows the relationship between all these classes. Figure 17.3. The SQLCommandBean and related classes The SQLCommandBean takes care of setting all values in a JDBC java.sql.PreparedStatement and executing the statement. For SELECT statements, it also processes the result by creating com.ora.jsp.sql.Row objects containing a com.ora.jsp.sql.Column object for each column in the result. The rows returned by the SELECT statement are returned to the caller as a java.util.Vector with Row objects. The EmployeeRegistryBean described in Chapter 15 is one example of how to use this bean, and other examples follow in this chapter. Let’s look at each class in detail, starting with the SQLCommandBean itself. page 242
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans

JavaSercer Pages The servlet class, defined by the (Web hosting india)

JavaSercer Pages The servlet class, defined by the element, is given a name through the element. A number of elements, with nested
and
elements, are used to define the following initialization parameters: jdbcDriverClassName, jdbcURL, dbUserName, and dbUserPassword. If you use a JDBC 2.0 connection pool, you need to define the URL used to get a reference from JNDI to it instead of all these parameters. The last servlet element, , tells the container that this servlet should be initialized when the web application is started. The container initializes servlets in the relative order specified by this element, from the lowest number to the highest. If two servlets have the same value, their relative start order is undefined. The servlet reads all the initialization parameters in its init( ) method, creates a DataSourceWrapper instance, and sets it as a ServletContext attribute named exampleDS: public void init( ) throws ServletException { ServletConfig config = getServletConfig( ); String jdbcDriverClassName = config.getInitParameter(”jdbcDriverClassName”); String jdbcURL = config.getInitParameter(”jdbcURL”); String dbUserName = config.getInitParameter(”dbUserName”); String dbUserPassword = config.getInitParameter(”dbUserPassword”); // Make sure a driver class and JDBC URL is specified if (jdbcDriverClassName == null || jdbcURL == null) { throw new UnavailableException(”Init params missing”); } DataSource ds = null; try { ds = new DataSourceWrapper(jdbcDriverClassName, jdbcURL, dbUserName, dbUserPassword); } catch (Exception e) { throw new UnavailableException(”Cannot create connection pool” + “: ” + e.getMessage( )); } getServletContext( ).setAttribute(”exampleDS”, ds); } All servlets and JSP pages in the application can now obtain a reference to the DataSource. Servlets use the ServletContext getAttribute( ) method to accomplish this. For JSP pages, the DataSource appears as an application scope object. All the database custom actions introduced in Chapter 9 look for a DataSource in the application scope, so all you have to do to use the one created by the initialization servlet is to provide the name: <%@ page language="java" contentType="text/html" %> <%@ taglib uri="/orataglib" prefix="ora" %> SELECT * FROM Employee WHERE FirstName LIKE ? AND LastName LIKE ? AND Dept LIKE ? ORDER BY LastName Note how the dataSource attribute value matches the name of the ServletContext attribute holding the reference to the DataSource, set by the initialization servlet. It’s much better to let an initialization servlet create the DataSource, as described here, than to use the custom action described in Chapter 9. With a servlet, all information about the JDBC driver class, URL, user and password is in one place (the WEB-INF/web.xml file), as opposed to being repeated in every JSP page that uses the database custom actions. This makes it easier to change the information when needed. Also, if you decide at some point to use another connection pool implementation, such as a true JDBC 2.0 connection pool available from your JDBC driver or database vendor, you can easily change the servlet’s init( ) method. So even for a pure JSP application, I recommend that you use an application initialization servlet like the one described here. page 241
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check professional tomcat hosting services

JavaSercer Pages The DataSourceWrapper class implements the DataSource (Web hosting paypal)

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

Java hosting - JavaSercer Pages public void clearWarnings( ) throws SQLException

JavaSercer Pages public void clearWarnings( ) throws SQLException { if (isClosed) { throw new SQLException(”Pooled connection is closed”); } realConn.clearWarnings( ); } … } An instance of this class is associated with a real Connection object, retrieved from a connection pool, through the constructor. The constructor also provides a reference to the DataSourceWrapper instance that creates it, described next. The ConnectionWrapper class implements the Connection interface. The implementations of all the methods except two simply relay the call to the real Connection object so it can perform the requested database operation. The implementation of the close( ) method, however, doesn’t call the real Connect object’s method. Instead, it calls the DataSourceWrapper object’s return-Connection( ) method, to return the Connection to the pool. The isClosed( ) method, finally, returns the state of the ConnectionWrapper object as opposed to the real Connection object. Example 17.2 shows how the com.ora.jsp.sql.DataSourceWrapper gets a connection from a pool, and returns it when the pool client is done with it. Example 17.2. The DataSourceWrapper Class package com.ora.jsp.sql; import java.io.*; import java.sql.*; import javax.sql.*; public class DataSourceWrapper implements DataSource { private ConnectionPool pool; public DataSourceWrapper(String driverClass, String url, String user, String pw) throws ClassNotFoundException, InstantiationException, SQLException, IllegalAccessException { pool = new ConnectionPool(url, user, pw, driverClass, 1, 1); } /** * Gets a connection from the pool and returns it wrapped in * a ConnectionWrapper. */ public Connection getConnection( ) throws SQLException { return new ConnectionWrapper(pool.getConnection( ), this); } /** * Returns a Connection to the pool. This method is called by * the ConnectionWrapper’s close( ) method. */ public void returnConnection(Connection conn) { pool.returnConnection(conn); } /** * Always throws a SQLException. Username and password are set * in the constructor and can not be changed. */ public Connection getConnection(String username, String password) throws SQLException { throw new SQLException(”Not supported”); } public int getLoginTimeout( ) throws SQLException { throw new SQLException(”Not supported”); } public PrintWriter getLogWriter( ) throws SQLException { throw new SQLException(”Not supported”); } public void setLoginTimeout(int seconds) throws SQLException { throw new SQLException(”Not supported”); } public synchronized void setLogWriter(PrintWriter out) throws SQLException { throw new SQLException(”Not supported”); } } page 239
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services

Comcast web hosting - JavaSercer Pages The interaction between the wrapper classes

JavaSercer Pages The interaction between the wrapper classes and a connection pool implementation is illustrated in Figure 17.2. Figure 17.2. A JDBC 1.0 connection pool wrapped with JDBC 2.0 interface classes Figure 17.2 can be explained like this: the application calls the DataSourceWrapper getConnection( ) method. The DataSourceWrapper obtains a Connection object from its ConnectionPool object. The ConnectionPool either finds an available Connection in its pool or creates a new one. The DataSourceWrapper creates a new ConnectionWrapper object for the Connection it obtained, and returns the ConnectionWrapper to the application. The application uses the ConnectionWrapper object as a regular Connection. The ConnectionWrapper relays all calls to the corresponding method in the Connection it wraps, except for the close( ) method. When the application calls the close( ) method, the ConnectionWrapper returns its Connection to the DataSourceWrapper, which in turn returns it to its ConnectionPool. In this example, I show you how to wrap the connection pool described in Jason Hunter and William Crawford’s Java Servlet Programming (O’Reilly). It’s a simple implementation, intended only to illustrate the principles of connection pooling. The source code for the connection pool is included with the code for this book, but I will not discuss the implementation of the pool itself, only how to make it look like a JDBC 2.0 connection pool. For production use, I recommend that instead of this code, you use a pool intended for real use, such as one of the implementations mentioned earlier. The first wrapper class is called com.ora.jsp.sql.ConnectionWrapper , shown in Example 17.1. Example 17.1. The ConnectionWrapper Class package com.ora.jsp.sql; import java.sql.*; import java.util.*; class ConnectionWrapper implements Connection { private Connection realConn; private DataSourceWrapper dsw; private boolean isClosed = false; public ConnectionWrapper(Connection realConn, DataSourceWrapper dsw) { this.realConn = realConn; this.dsw = dsw; } /** * Inform the DataSourceWrapper that the ConnectionWrapper * is closed. */ public void close( ) throws SQLException { isClosed = true; dsw.returnConnection(realConn); } /** * Returns true if the ConnectionWrapper is closed, false * otherwise. */ public boolean isClosed( ) throws SQLException { return isClosed; } /* * Wrapped methods. */ page 238

Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Sandzak.com j2ee web hosting services

Comcast webspace - JavaSercer Pages javax.sql.ConnectionPoolDataSource A DataSource implementation that provides

JavaSercer Pages javax.sql.ConnectionPoolDataSource A DataSource implementation that provides pooling capabilities uses a class that implements the ConnectionPoolDataSource interface. A ConnectionPoolDataSource is a factory for PooledConnection objects. Figure 17.1 outlines how an application uses implementations of these interfaces to obtain a pooled connection and how to return that connection to the pool. Figure 17.1. Application using a JDBC 2.0 connection pool The application calls the DataSource getConnection( ) method. The DataSource looks for an available PooledConnection object in its pool. If it doesn’t find one, it uses its ConnectionPoolDataSource object to create a new one. It then calls the getConnection( ) method on the PooledConnection object and returns the Connection object associated with the PooledConnection. The application uses the Connection, and calls its close( ) method when it’s done. This results in a notification event being sent to the DataSource, which puts the corresponding PooledConnection object back in the pool. If you would like to learn more about the JDBC 2.0 connection pool model, you can download the JDBC 2.0 Optional Package specification from http://java.sun.com/products/jdbc/. The real beauty of these interfaces is that the application doesn’t have to be aware that it’s using a connection pool. All configuration data, such as which JDBC driver and JDBC URL to use, the initial and maximum numbers of pooled connections, and the database account name and password, can be set by a server administrator. The completely configured DataSource object is registered as a JNDI resource, and the application can obtain a reference to it with the following code: Context ctx = new InitialContext( ); DataSource ds = (DataSource) ctx.lookup(”jdbc/EmployeeDB”); It then gets a Connection, uses it, and returns it with the following code: Connection conn = ds.getConnection( ); // Uses the Connection conn.close( ); // Returns the Connection to the pool By implementing these JDBC 2.0 interfaces, JDBC driver and middleware vendors can offer portable connection pooling implementations. Sun’s JDBC driver list contains roughly ten different companies that claim to either offer implementations of connection pools today or have announced products to be delivered during 2000. 17.1.2 Making a JDBC 1.0 Connection Pool Behave as a JDBC 2.0 Connection Pool If you can’t find a JDBC 2.0 connection pool implementation for your database, there are plenty of implementations based on JDBC 1.0 available. I describe one in an article I wrote for the Web Developer’s Journal, titled “Improved Performance With a Connection Pool,” available at http://www.webdevelopersjournal.com/columns/connection_pool.html. Another is the DBConnectionBroker , available at http://www.javaexchange.com. It’s easy to develop a couple of wrapper classes for one of these implementations so that it can be used in place of a JDBC 2.0 connection pool implementation. This way, you can switch out the JDBC 1.0 pool with a JDBC 2.0 pool when one becomes available from your database vendor or a third party. page 237

Hint: This post is supported by Gama web hosting php mysql provider

Frontpage hosting - JavaSercer Pages A connection is expensive to keep

JavaSercer Pages A connection is expensive to keep open in terms of server resources such as memory. Many commercial database products also use licenses that are priced based on the number of simultaneously open connections, so a connection can also be expensive in terms of real money. Therefore, it’s wise to try to minimize the number of connections the application needs. An alternative to the “one Connection per resource” approach is to create a Connection for each user when the first request is received and keep it as a session scope object. However, a drawback with this approach is that the Connection will be inactive most of the time, since the user needs time to look at the result of one request before making the next. The best alternative is to use a connection pool. A connection pool contains a number of Connection objects shared by all servlets and JSP pages. For each request, one Connection is checked out, used, and checked back in. Using a pool solves the problems described for the other alternatives: It’s time-consuming to create a Connection. A pooled Connection is created only once and then reused. Most pool implementations let you specify an initial number of Connection objects to create at startup, as well as a max number. New Connection objects are created as needed up to the max number. Once the max number has been reached, the pool clients wait until an existing Connection object becomes available instead of creating a new one. There are multithreading problems with a shared Connection. Each request gets its own Connection, so it’s used by only one thread at a time, eliminating any potential multithreading issues. A Connection is a limited resource. With a pool, each Connection is used efficiently. It never sits idle if there are requests pending. If the pool allows you to specify a max number of Connection objects, you can also balance a license limit for the number of simultaneous connections against acceptable response times. A connection pool, however, doesn’t solve all problems. Since all users are using the same Connection objects, you cannot rely on the database engine to limit access to protected data on a per-user basis. Instead, you have to define data access rules in terms of roles (groups of users with the same access rights). You can then use separate pools for different roles, each pool creating Connection objects with a user account that represents the role. 17.1.1 Using a JDBC 2.0 Optional Package Connection Pool Connection pools exist in many forms. You can find them in books, articles, and on the Web. Yet prior to JDBC 2.0, there was no standard defined for how a Java application would interact with a connection pool. The JDBC 2.0 Optional Package (formerly known as a Standard Extension) changes this by introducing a set of interfaces that connection pools should implement: javax.sql.PooledConnection The objects that a DataSource keeps in its pool implement the PooledConnection interface. When the application asks the DataSource for a Connection, it locates an available PooledConnection object, or gets a new one from its ConnectionPoolDataSource if the pool is empty. The PooledConnection provides a getConnection( ) method that returns a Connection object. The DataSource calls this method and returns the Connection to the application. This Connection object behaves like a regular Connection with one exception: when the application calls the close( ) method, instead of closing the connection to the database, it informs the PooledConnection it belongs to that it’s no longer being used. The PooledConnection relays this information to the DataSource, which returns the PooledConnection to the pool. javax.sql.DataSource A DataSource represents a database. This is the interface the application always uses to get a Connection. The class that implements the interface can provide connection pooling capabilities or hand out regular, unpooled Connection objects; the application code is identical for both cases, as described later. page 236
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

JavaSercer Pages Chapter 17. Developing Database Access Components (Web hosting ssh)

JavaSercer Pages Chapter 17. Developing Database Access Components In this final chapter, we look at more examples of how to develop custom actions, namely the database custom actions introduced in Chapter 9. Before digging into the code for these actions, a number of fundamental Java database access features are discussed. First, we take a look at the JDBC Connection class, and how pooling Connection objects helps solve a number of common problems. We look at two ways to provide connection pooling capabilities to an application: with JDBC 2.0, and by letting a JDBC 1.0 connection pool simulate a JDBC 2.0 pool. The purpose of a connection pool is to be able to share database connections between all components of an application. The approach discussed in this chapter is to use an application initialization servlet that makes the pool available to all servlets and JSP pages. No matter if you use a servlet or a custom action in a JSP page to access the database, there are a number of things to think about. We look at a generic database access bean and related classes that take care of datatype issues and make the result of a query easy to access. Next, we look at how the bean is used by the database access custom actions described in Chapter 9. You can also use the bean directly in servlets, as described in Chapter 15, or in your own application-specific database access actions. The last section contains an example of an application-specific custom action using the bean. To really appreciate the material in this chapter, you should already be familiar with JDBC. If this is not the case, I recommend that you look at the JDBC documentation online at http://java.sun.com/products/jdbc/ or read a book about JDBC, such as George Reese’s Database Programming with JDBC and Java (O’Reilly). 17.1 Using Connections and Connection Pools In a JDBC-based application, a lot revolves around the java.sql.Connection interface. Before any database operations can take place, the application must create a Connection to the database. It then acts as the communication channel between the application and the database, carrying the SQL statements sent by the application and the results returned by the database. A Connection is associated with a database user account, to allow the database to enforce access control rules for the SQL statements submitted through the Connection. Finally, the Connection is also the boundary for database transactions. Only SQL statements executed through the same Connection can make up a transaction. A transaction consists of a number of SQL statements that must either all succeed or all fail as one atomic operation. A transaction can be committed (the changes resulting from the statements are permanently saved) or rolled back (all changes are ignored) by calling Connection methods. In a standalone application, a Connection is typically created once and kept open until the application is shut down. This is not surprising, since a standalone application serves only one user at a time, and all database operations initiated by a single user are typically related to each other. In a server application that deals with unrelated requests from many different users, it’s not so obvious how to deal with connections. There are three things to consider: a Connection is time-consuming to create, it must be used for only one user at a time to avoid transaction clashes, and it is expensive to keep open. Creating a Connection is an operation that can actually take a second or two to perform. Besides establishing a network connection to the database, the database engine must authenticate the user and create a context with various data structures to keep track of transactions, cached statements, results, and so forth. Creating a new Connection for each request received by the server, while simple to implement, is far too time- consuming in a high-traffic server application. One way to minimize the number of times a connection needs to be created is to keep one Connection per servlet or JSP page that need access to the database. A Connection can be created when the web resource is initialized, and kept in an instance variable until the application is shut down. As you will discover when you deploy an application based on this approach, this route will lead to numerous multithreading issues. Each request executes as a separate thread through the same servlet or JSP page. Many JDBC drivers do not support multiple threads accessing the same Connection, causing all kinds of runtime errors. Others support it by serializing all calls, leading to poor scalability. An even more serious problem with this approach is that requests from multiple users, all using the same Connection, operate within the same transaction. If one request leads to a rollback, all other database operations using the same Connection are also rolled back. page 235
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services

JavaSercer Pages The WEB-INF/web.xml file must then contain (Tomcat hosting)

JavaSercer Pages The WEB-INF/web.xml file must then contain the following elements: … /orataglib /WEB-INF/lib/orataglib_1_0.jar … The element contains the symbolic name, and the element contains the path to either the JAR file or the extracted TLD file. page 234
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans