Working with KB properties – Isolation Level

We faced a record lock issue some time back where our program was fetching values for a particular record from a transaction. If the record we were trying to read from, was open in Edit mode at the backend (AS/400), the procedure trying to read the data was getting aborted saying the Record has been locked (Java Front End). The easiest way to solve this issue was to change the Isolation Level property from Read Committed to Read Uncommitted.

Isolation Level Property in Java Web generator can be very useful for minimizing the Record Locks. GeneXus EV2 provides two types of Isolation Levels. 

1. Read Committed – The changes from one user are not available for the other users unless the changes are committed. So a transaction executing under this isolation level can only access the committed data. This is a default setting.

Pros: Data retrieved is consistent.

Cons: Can throw Record Locks and abort the process.

  

2. Read Uncommitted – The changes from one user are available for all users even if not committed. (This usually is a dirty read). So, if the first user updates some data, it can be read by other users even though first user can do the rollback of the read updates.

Pros: Quick performance, No record locks.

Cons: Data received may be inconsistent.