Feature Request: Allowing dirty read capability beyond ETX 1.31.xC2

IDS 11.70.FC7W2
OS AIX 6.1
ETX version
expression) DataBlade version:
Excalibur Text DataBlade Release 1.31.FC1X3

Problem:
Due to the fix of IC73561 may have introduced the new behaviors on 1.31.xC2 that impact customer's current operation.

Customer use ETX in OLTP environment. If a particular query runs too long say 5 minutes, all the rest of the queries and updates will have to wait for that long to continue processing.
On average each query will run anywhere from 10 to 60 seconds.

On 1.31.xC1 can assert fail when ETX dirty reads occur because the server was not designed to support dirty reads on ETX Large Objects. The defect IC73561 here was determined that we should not have allowed dirty reads.
On 1.31.xC2, with IC73561, development decided to fix this defect by having readers wait and retry while a writer is doing ETX Large Object manipulation. There is no other fix that will circumvent these dirty read
relevant assertion failures.

New behavior introduced in 1.31.xC2 as below:
- when a reader encounters a writer who has a lock doing LO navigating and change,
- the reader will stay on and keep trying certain times
- the reader will proceed when the writer finishes the LO navigating within the trying period
- the reader will return the lock error after try certain times and allow user to check the status and re-try the read
- currently not allow user to change that certain times (currently it try 20 times) in order to avoid complicated deadlock


NOTE:
Customer said workaround of Running on secondary is not being considered at the moment as secondary is used for DSS queries.

Hence, customer wishes to having dirty read capability beyond 1.31.xC2; or other alternative which allows them to overcome the changes put in 1.31.xC2 or avoid the AF crash ( due to idsdb00186209) that happens in current ETX 1.31.XC1.