Fix (APAR): PK15508 Status: Fix Release: 6.0.2.6,6.0.2.5 Operating System: AIX,HP-UX,Linux,Linux Red Hat - pSeries,Linux zSeries,OS/390,OS/400,Solaris,Windows,z/OS Supersedes Fixes: CMVC Defect: PK15508 Byte size of APAR: 61400 Date: 2006-01-12 Abstract: IssolationLevelChangeException occurs when an application containing CMP 1.1 EJBs is restarted without restarting the WebSphere Applicaiton Server. This problem is related to appli Description/symptom of problem: PK15508 resolves the following problem: ERROR DESCRIPTION: IssolationLevelChangeException occurs when an application containing CMP 1.1 EJBs is restarted without restarting the WebSphere Server. This problem is related to applications containing 1.1 EJBs only. LOCAL FIX: Fix is being worked on and will be provided in 6.0.2 service pack PROBLEM SUMMARY USERS AFFECTED: All WebSphere Application Server version 6 applications containing Version 1.1 EJBs. PROBLEM DESCRIPTION: IssolationLevelChangeException occurs when an application containing CMP 1.1 EJBs is restarted without restarting the WebSphere Applicaiton Server. This problem is related to applications containing 1.1 EJBs only. RECOMMENDATION: None This problem is somewhat bizzarre and is not easy to get into. Here is one scenario that reproduced the problem: Have a Stateless Session Bean (SLSB) which calls a finder on a CMP 1.1 Entity Bean (EB) on WebSphere Application Server version 6.0 (it is important to note that this problem can only happen on version 6.0). You must run thisscenario twice. For the first run the SLSB looks up the EB and "caches" a copy of the EB home. When the SLSB looks up the EB, this causes the EB to be initialized. Then call a finder on the home. So far everything works as expected. Next, stop and restart ONLY the application containing the EB. Then run the scenario again. This time the SLSB doesn't need to look up the EB home, rather it uses its "cached" instance of the home. With the cached version of the home, the SLSB calls the same finder on the EB. Calling the method on this EB causes the EB to be initialized (it needs to be initialized since it was cycled). The key thing to notice here is that in both runs, the EB is initialized which is the correct behavior. However, in the two cases, the path to the initialization is slightly different. In the first case, during the home look-up, the current transaction is suspended and as such the initialization doesn't run within the user's transaction context. After the look-up completes the transaction is resumed. In the second case, since it didn't do a naming look up, the code path is different. In this case the initialization is performed within the user's global transaction (that is the current transaction is not suspended). The problem with this is that during the initialization of the EB, a 'default' isolation level (REPEATABLE_READ) is associated with the user's tranaction. This is important because after the initialization happens the finder is actually called, at which time the isolation level (READ_COMMITTED) associated with the finder is attempted to be set on the transaction. Since the isolation level associated with the transaction is REPEATABLE_READ, an exception is thrown because an isolation level can't be changed for the life of a transaction (except in the case where the isolation level is TRANSACTION_NONE. In that case the isolation level can be changed to something else. PROBLEM CONCLUSION: By applying this fix, the scenario described above is properly handled and an IsolationLevelChangeException is not thrown. The fix for this APAR is currently targeted for inclusion in fixpack 6.0.2.9. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980 Directions to apply fix: NOTE: Choose the: 1) Release the fix applies to 2) The Editions that apply 3) Delete the Editions & Methods that do not apply and this Note Fix applies to Editions: Release 6.0 _x_ Application Server (Express or BASE) _x_ Network Deployment (ND) _x_ WebSphere Business Integration Server Foundation (WBISF) _x_ Edge Components _x_ Developer _x_ Extended Deployment (XD) Install Fix to: Method: __ Application Server Nodes __ Deployment Manager Nodes _x_ Both NOTE: The user must: * Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 For detailed instructions to Extract the Update Installer see the following Technote: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21205400 1) Copy 6.0.2.5-WS-WAS-IFPK15508.pak file directly to the maintenance directory 2) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Select the "Install maintenance package" operation. 6) Enter the file name of the maintenance package to install (6.0.2.5-WS-WAS-IFPK15508.pak file which was copied in the maintenance directory). 7) Install the maintenance package. 8) Restart WebSphere Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (6.0.2.5-WS-WAS-IFPK15508.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere. Additional Information: