|
| Problem | In versions of WebSphereŽ Application Server prior to V3.5.7, it is possible for two servlets to be assigned the same session ID. This will result in a DuplicateKeyException when the second servlet attempts to update the session table. | | Cause | In versions of WebSphereŽ Application Server 3.5 prior to V3.5.7, the session manager does not update the session cache with a newly created session ID until the session table has been updated. The session does not actually get inserted into the session table until the servlet service method completes. This means that it is possible for servlet A to create a new session ID, and for servlet B to allocate the same ID before servlet A completes. In this situation, it is possible for servlet B to request the same ID that has already been assigned to servlet A. Servlet A will complete first and the session manager will insert the session ID into the session table. When servlet B completes, the session manager will attempt to insert the same session ID into the session table, resulting in a DuplicateKeyException. If the session database is DB2, you will see the following exception stack :
com.ibm.ejs.cm.portability.DuplicateKeyException: [IBM][CLI Driver][DB2/SUN]
SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "" constrains table "" from having duplicate rows for those columns. SQLSTATE=23505
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.<init>(Throwable.java:94)
at java.lang.Exception.<init>(Exception.java:42)
at java.sql.SQLException.<init>(SQLException.java:43)
at com.ibm.ejs.cm.portability.PortableSQLException.<init>(PortableSQLException.java:22)
at com.ibm.ejs.cm.portability.DuplicateKeyException.<init>(DuplicateKeyException.java:13)
at java.lang.reflect.Constructor.newInstance(Native Method)
at com.ibm.ejs.cm.portability.PortabilityLayerImpl.translateException(PortabilityLayerImpl.java:169)
at com.ibm.ejs.cm.pool.ConnectO.translateException(ConnectO.java:1159)
at com.ibm.ejs.cm.proxy.ConnectionProxy.translateException(ConnectionProxy.java:177)
at com.ibm.ejs.cm.proxy.PreparedStatementProxy.translateException(PreparedStatementProxy.java:484)
at com.ibm.ejs.cm.proxy.PreparedStatementProxy.executeUpdate(PreparedStatementProxy.java:238)
at com.ibm.servlet.personalization.sessiontracking.BackedHashtable.ejbCreate(BackedHashtable.java:3542)
at com.ibm.servlet.personalization.sessiontracking.BackedHashtable.insertSession(BackedHashtable.java:2847)
If you follow the stack down far enough, you can see that the DuplicateKeyException is being thrown as a result of the BacketHashtable.insertSession() call. | | Solution | This defect was fixed in apar pq59155, which has been replaced by pq63816. The session manager now updates the session cache with the session ID at the time of creation. You can fix this problem in one of two ways:- Apply pq63816 which is available for download on the WebSphere support site
- Upgrade to WebSphere Application Server V3.5.7
| |
| | |
| |
|
Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Sessions and Session Management Operating system(s): Multi-Platform Software version: 3.5, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.5.4.1, 3.5.4.2, 3.5.5, 3.5.6 Software edition: Edition Independent Reference #: 1156413 IBM Group: Software Group Modified date: 2003-12-30
(C) Copyright IBM Corporation 2000, 2004. All Rights Reserved.
|