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

Because WAS provides backward compatibility with application modules coded to the J2EE 1.2 specification, one can continue to use V4 style data sources when you migrate to Application Server V6.x. As long as you configure V4 data sources only for J2EE 1.2 modules, the behavior of your data access application components does not change.

If you are adopting a later version of the J2EE specification along with your migration to Application Server V6.x, however, the behavior of your data access components can change. Specifically, this risk applies to applications that include servlets, JavaServer Page (JSP) files, or enterprise session beans that run inside local transactions over shareable connections. A behavior change in the data access components can adversely affect the use of connections in such applications.

This change affects all applications that contain the following methods:

  • RequestDispatcher.include()

  • RequestDispatcher.forward()

  • JSP includes (<jsp:include>)

Symptoms of the problem include:

  • Session hang

  • Session timeout

  • Run out of connections

Note: We can also experience these symptoms with applications that contain the components and methods described previously if you are upgrading from J2EE 1.2 modules within Application Server V6.x.

 

Explanation of the underlying problem

For J2EE 1.2 modules using V4 data sources, WAS issues non-sharable connections to JSP files, servlets, and enterprise session beans. All of the other application components are issued shareable connections. However, for J2EE 1.3 and 1.4 modules, Application Server issues shareable connections to all logically named resources (resources bound to individual references) unless you specify the connections as unshareable in the individual resource-references. Using shareable connections in this context has the following effects:

  • All connections that are 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() call.

  • All connections that are 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 beans).

    For example, 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.

If you do not anticipate this change in the connection behavior, the way you structure your application code can lead to excessive connection use, particularly in the cases of JSP includes, session beans that run inside local transactions over shareable connections, RequestDispatcher.include()routines, RequestDispatcher.forward() routines, or calls from these methods to other components.

 

Examples of the connection behavior change

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. Because the servlet A connection does not return to the free pool until it returns 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 results in ConnectionWaitTimeOut exceptions. If the 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 do not return the ones they are currently using if new connections are not available.

 

Alternatives to the connection behavior change

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() call (assuming you commit or roll 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.

 

See Also


Connection wait timeout
Unshareable and shareable connections

 

See Also


JDBC and data source troubleshooting tips

 

Related Information


http://www-3.ibm.com/software/webservers/appserv/doc/latest/prereq.html