Data access migration considerations

Note: These considerations are applicable for J2EE 1.3 data access applications. If you followed the procedure to Migrate a Version 4 data access application to Version 5 in the Migration topic, refer to the information below. If you migrated your application server instance wihtout migrating the existing data access applications, this information is not applicable, because your applications remain at the J2EE 1.2 specification.

If you migrated from WAS Version 3.5 or Version 4 to WAS Version 5, and you run servlets, JavaServer Page (JSP) files, or enterprise session beans with bean managed transactions, a behavior change in the data access component can adversely affect the use of connections in your 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
• Running out of connections

In WAS Version 4 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, 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:

• 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().

• 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 of the connection behavior change

If you did not anticipate this change in the connection 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 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. 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 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 will 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(), (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).

For more information on data access application migration, see Migrate a Version 4 data access application to Version 5 in the Migration topic.