[#1950] Adds support for TRANSACTION_CURSOR_STABILITY and TRANSACTION_LAST_COMMITTED #1952
Conversation
…and TRANSACTION_LAST_COMMITTED TRANSACTION_LAST_COMMITTED - This allows a readonly user to access a row and read the last commited data while Informix has an open lock against the data. Unlike TRANSACTION_READ_UNCOMMITTED which would also accomplish the same but would end up allowing dirty reads. This would lead to us reading data that's potentially either rolledback or never actually commited. TRANSACTION_CURSOR_STABILITY - Cursor stability will place a lock on a row as it's fetched which ensures that the data doesn't change while the program reads the data. Documentation for cursor stability can be found here https://www.ibm.com/docs/en/informix-servers/12.10?topic=level-informix-cursor-stability-isolation Documentation on Informix transaction isolation levels are here https://www.ibm.com/docs/en/informix-servers/12.10?topic=database-informix-environment-variables-informix-jdbc-driver
Codecov Report
@@ Coverage Diff @@
## dev #1952 +/- ##
============================================
- Coverage 70.37% 70.26% -0.12%
+ Complexity 572 569 -3
============================================
Files 26 26
Lines 2164 2166 +2
Branches 311 311
============================================
- Hits 1523 1522 -1
- Misses 492 493 +1
- Partials 149 151 +2
Continue to review full report at Codecov.
|
|
@brettwooldridge This seems reasonable to me, but presumably there are other isolation levels as well. Why stop here, is there a way to support everything without HikariCP having to know? |
|
As the Ifxconnection extends java.sql.connection and I suspect most of them would. It might be possible to just expect an instance of java.sql.connection to be passed in. That would likely result in a breaking change though. https://javadoc.io/static/com.ibm.informix/jdbc/4.10.9/com/informix/jdbc/IfxConnection.html |
TRANSACTION_LAST_COMMITTED - This allows a readonly user to access a row and read the last commited data while Informix has an open lock against the data.
Unlike TRANSACTION_READ_UNCOMMITTED which would also accomplish the same but would end up allowing dirty reads. This would lead to us reading data that's potentially either rolledback or never actually commited.
TRANSACTION_CURSOR_STABILITY - Cursor stability will place a lock on a row as it's fetched which ensures that the data doesn't change while the program reads the data.
Documentation for cursor stability can be found here https://www.ibm.com/docs/en/informix-servers/12.10?topic=level-informix-cursor-stability-isolation
Documentation on Informix transaction isolation levels are here https://www.ibm.com/docs/en/informix-servers/12.10?topic=database-informix-environment-variables-informix-jdbc-driver