Connection considerations when migrating servlets, JavaServer Pages, or enterprise session beans

If you are migrating from Websphere Application Server Version 3.5.x or Version 4.0.x to WebSphere Application Server Version 5.0.x, and you are running servlets, JavaServer Page (JSP) files, or enterprise session beans with bean managed transactions, a behavior change in the data access component can adversly affect the use of connections in your applications.

This change affects all applications that contain the following methods:

Symptoms of the problem include:

In Websphere Application Server Version 4.0.x and earlier releases, JSP files, servlets, and enterprise session beans with bean managed transactions are issued non-sharable connections, while all the other components are issued shareable connections.

Starting with Websphere Version 5.0.x, all connections that are accessed with a resource-reference, default to shareable unless specified unshareable in the resource-reference. This change is required for compliance with the J2EE 1.3 Specification. Using shareable connections in this context has the following effects:

  1. All connections received and used outside the scope of a user transaction are not returned to the free connection pool until the encapsulating method returns, even when the connection handle issues a close().
  2. All connections received and used outside the scope of a user transaction are not shared with other component instances (that is, other servlets, JSP files, or enterprise java beans).

    For example, if session bean 1 gets a connection and then calls session bean 2 that also gets a connection, even if all properties are identical, each session bean receives its own connection.

Implications

If you did not anticipate this behavior, the way you structure your application code could lead to excessive connection use, particularly in the cases of JSP includes, RequestDispatcher.include() routines, RequestDispatcher.forward() routines, session beans with bean managed transactions, or calls from these methods to other components.

Examples

Servlet A gets a connection, completes the work, commits the connection, and calls close() on the connection. Next, servlet A calls the RequestDispatcher.include() to include servlet B, which performs the same steps as servlet A. Since the servlet A connection did not return to the free pool until it returned from the current method, two connections are now busy. In this way, more connections might be in use than you intended in your application. If these connections are not accounted for in the Max Connections setting on the connection pool, this behavior might cause a lack of connections in the pool, which would result in ConnectionWaitTimeOutExceptions. If connection wait timeout is not enabled, or if the connection wait timeout is set to a large number, these threads might appear to hang because they are waiting for connections that are never returned to the pool. Threads waiting for new connections will not return the ones they are currently using if new connections are not available.

Alternatives

To resolve these problems:

  1. Use unshared connections.

    If you use an unshared connection and are not in a user transaction, the connection is returned to the free pool when you issue a close(), (assuming you committed or rolled back the connection).

  2. Increase the maximum number of connections.

    To calculate the number of required connections, multiply the number of configured threads by the deepest level of component call nesting (for those calls that use connections). See the Examples section for a description of call nesting.