Issue Information
| Issue Number | 701336a |
| Issue | When a physical connection is reused from the connection pool, the isolation level (ISOLATION LEVEL) set in the previous logical session is not reset and is carried over to the next session. As a result, the client and server may have inconsistent perceptions of the isolation level, causing concurrent update errors (ERROR_TX_CANT_SERIALIZE) in transactions unintentionally subject to the SERIALIZABLE isolation level, or result errors in which calculations are performed using stale data without seeing commits from other sessions due to a contaminated session. |
| Cause | When the DBC client sends a session initialization command to reuse a physical connection from the connection pool, the server restores the session to its initial state but fails to reset only the transaction isolation level setting; other settings are reset normally. |
| Solutions | When the JDBC client reuses a physical connection from the connection pool, the server is modified to also reset the changed transaction isolation level setting while restoring the session to its initial state. |
| Occurrence Date | 26.08.31. |
| Required Patch Version | 6FS07PS 7FS02PS |
Patch Information
| Patch Name | FS02PS_701336a |
| Major Version | 7 |
| Minor Version | FS02PS |
| Version Title | RESET_SESS Protocol Does Not Reset the Session Isolation Level |
| Available for Deployment | 26.11.02. |
| Compatibility | • TAC rolling patch: Available • TSC rolling patch: Available • Backup data compatibility: Available • Protocol compatibility: Available • Data format compatibility: Available |
| AP Impact | • Plan change: No • Result value change: Yes • SQL syntax change: No • System object change: No • Existing functionality change: No |
| Parameters | - |
| Workaround | - Remove the use of SERIALIZABLE itself - Revert to READ COMMITTED when code using SERIALIZABLE ends - Prevent physical connection reuse |