Shareable versus Unshareable connection in WebSphere Application Server V4 and V5
 Technote (FAQ)
 
Problem
When migrating from WebSphere® Application Server V4.0 or lower to WebSphere Application Server V5.0 or higher, the connection pool changes from Unshareable to Shareable by default. This change can cause unexpected results or even an application server hang.
 
Cause
In J2EE 1.3, a new concept called resource sharing was introduced. Sharing resources, particularly data sources can lead to more efficient usage of those scarce resources and greater scalability. To achieve this goal, J2EE 1.3 also requests the container provider to use “ shareable connection” as the default setting unless users explicitly set “ unshareable” in the deployment descriptor element res-sharing-scope.

The change of default behavior could be an issue for existing enterprise application, especially for those migrated from releases of WebSphere Application Server V4.0. Because, in WebSphere Application Server V4.0 and earlier releases, JSP files, servlets, and enterprise session beans with bean managed transactions are issued un-shareable connections only. If such applications migrate to WebSphere Application Server V5.0 and later versions without modifying the codes or redefining the resources as “ unshareable”, developers might experience an application hang due to connection pool exhausting.

This issue will become apparent for servlet with extensive nesting calls or long transactions. For instance, servlet A starts a transaction, then calls servlet B, which in turn calls servlet. If every servlet requests shareable database connections, the shareable connections will be associated with this transaction until it finishes. Those connections will not return to the connection pool even a close connection command is issued, for shareable connection is designed to share within the scope of user transaction, but not outside. As a result, all those connections will be tied up and cannot be reused by other threads. In rare conditions, it can lead to deadlock.
 
Solution
To solve this problem, developers either need to explicitly set “unshareable” in the deployment descriptor element res-sharing-scope; or to modify the codes to reduce the nested calls, and limit the scope of transaction.

Some developers also create user-spawned threads in WebSphere Application Server though it is generally not recommended. The behaviors of user threads versus WebSphere Application Server threads in V5.0 are as follows:
  • For user spawned threads, the connection will always be unshareable regardless how the resources reference defines the connection pool.

  • For WebSphere Application Server threads, such as servlet, the nature of the connections depend on how the data sources are looked up:
    • If the data source is obtained through direct JNDI look-up (for example: iiop://hostname:dsname), the connection will use the default setting according to J2EE specification 1.3, which is shareable. The definition in resource reference is irrelevant.

    • If the data source is obtained through indirect look-up (for example: java:comp/env:jdbc/dsname), then the connections will follow the definition in the resource reference.

When migrating from WebSphere Application Server V4.0 and earlier to WebSphere Application Server V5.0 and later, developers should keep in mind the change of the default setting and the difference in behaviors. Developers need to carefully evaluate their applications, and if necessary, modify their code.
 
Related information
Unshareable and shareable - V5.0 Information Center
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers WebSphere Application Server - Express AIX, HP-UX, Linux, Solaris, Windows 5.0, 5.1 Express
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > DB Connections/Connection Pooling
Operating system(s): HP-UX
Software version: 4.0
Software edition:
Reference #: 1217545
IBM Group: Software Group
Modified date: Sep 19, 2005