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 passed on to the next session. As a result, the isolation level recognized by the client and server becomes inconsistent, which may cause a concurrent update error (ERROR_TX_CANT_SERIALIZE) in a transaction unintentionally subject to the SERIALIZABLE isolation level, or may result in an error where 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. |
| Version Requiring the Patch | 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 Date | 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 |
| Parameter | - |
| Workaround | - Remove the use of SERIALIZABLE itself - Revert to READ COMMITTED yourself when the code using SERIALIZABLE ends - Prevent physical connection reuse |