|
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. |
|
|
|
|
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 |
|
|
|
|