IFX_ISOLATION_LEVEL 2 vs 3
Sh To asked about the difference between IFX_ISOLATION_LEVEL 2 and 3, both documented as equivalent to READ COMMITTED. Art Kagel pointed to the SET ISOLATION documentation. Khaled Bentebal explained level 2 as Committed Read (no lock held after read) and level 3 as Cursor Stability (shared lock held on the current row until the next FETCH).
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello I d like to understand what are the differences between isolation level 2 and 3 Both of them are "equivalent to TRANSACTION_READ_COMMITTED " https://www.ibm.com/docs/en/informix-servers/14.10?topic=database-informix-environment-variables-informix-jdbc-driver Please, could someone redirect me to the right place that explains the subject. Thanks ------------------------------ Samuel ------------------------------ #Informix
Samuel: Here's the link to the SQL SET ISOLATION statement for Informix, the isolation levels are explained there: Help - HCL Informix V14.10 documentation Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------
------------------------------ ZhiWei Cui GBASE ------------------------------
Hi, First of all, all of the ISOLATION LEVELS apply to reads only , not UPDATES, DELETES, INSERTS. Level 2: Committed Read means that when you try to read a row using a SELECT, the server returns the row if it has been committed (no lock on it: not being updated at read time). The system tries to put a lock on that row but does not actually put the lock; if it possible to put a lock , that means no one is modifying it at that particular time. Hence it has been committed. However, nothing prevents others users modifying that row or even deleting it after the row was read. The row that was read was a real row that was committed when the read was done. The only guaranty is that the row was not being modified when it was read. Level 3: Cursor Stability (applies to reads using cursors only) means that when you try to read the row using a FETCH thru a cursor, the server returns the row if it has been committed and puts a shared lock on it. That lock stays until you realese the lock by fetching another row using FETCH NEXT. Others users can read the same row but no one can modify it while you are reading it. -- Cordialement, Regards, Khaled Bentebal Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr