PQ62537: USE SEQUELINK JDBC DRIVER FOR ORACLE OR SQLSERVER, CONNECTION MANAGER DOESN'T HANDLE EJB'S PROPERTY "FOR UPDATE" CORRECTLY

 A fix is available

4.0.2-4.0.7: Component cumulative Connection Manager fix



APAR status
Closed as program error.

Error description
The scenario which causes this problem is as follows:
1) Two separate clients, referred to from now on as t1 and t2,
are accessing the same database.  They both execute a SELECT
statement, which results in both transactions holding
read-locks on the database.
2) One of the transactions, say t1, attempts to execute an
UPDATE statement, requiring upgrading of its lock from read to
update status. This upgrade cannot be performed because t2 is
currently holding a read lock, so t1 must wait for t2 to
release its read lock.
3) t2 also attempts to execute an UPDATE statement, requiring
upgrading of its lock from read to update status.  This
upgrade cannot be performed because t2 is currently holding a
read lock, so t2 must wait for t1 to release its read lock.
DEADLOCK

4) Microsoft SQL server detects the deadlock, and forces one
of the transactions to rollback, allowing the other to
complete correctly.
.
The EJB is set to load as "for Update". This is a corect setup
but the Connection Manager code specific for SQL Server is not
being handled correctly. Everything is working fine with DB2.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users of    *
*                 Connection Pooling.                          *
****************************************************************
* PROBLEM DESCRIPTION: User's may experience hangs, the        *
*                      javacores would show a deadlock         *
*                      in Connection Management code.          *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
A condition existed, on a VERY fast multi-procesor system,
whereby one thread held a lock on a statement, trying to get
a lock on the connection, another thread had a lock on the
conection, trying to get a lock on the statement.
This could only happen when StaleConnection processing was
happening at the same millisecond as a transaction timeout
occurs.
Problem conclusion
The timing window for this to happen was removed.
Temporary fix Comments
Test Fix provided to customer
APAR information
APAR number PQ62537
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-06-21
Closed date 2002-08-12
Last modified date 2002-08-12

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
JDBC          

SRLS

Fix information
Fixed component name WEBSPHERE AE NT
Fixed component ID 5630A2201

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ62537
IBM Group: Software Group
Modified date: Aug 12, 2002