PQ62537: USE SEQUELINK JDBC DRIVER FOR ORACLE OR SQLSERVER, CONNECTION MANAGER DOESN'T HANDLE EJB'S PROPERTY "FOR UPDATE" CORRECTLY | |||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||
![]() 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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
SRLS
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.