Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss
Frontpage hosting - JavaSercer Pages A connection is expensive to keep
January 22, 2007 on 12:14 pm | In Java | 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
No Comments yet
Sorry, the comment form is closed at this time.
...I
just wanted to take the time to say "Thank you!" for our new webmail
system. It's great! Thanks for taking such good care of us.
Thanks
for helping me out. Just for the record, Webhostingjava.net has been a great
web host! So far your support and handling of questions has far
exceeded that of a "larger web hosting company".
I
would like to thank you for helping me with my domain...You have
shown me great patience and professionalism. I would not hesitate to
recommend you to my clients.