Uncommitted transaction data visible in E1 - "Dirty Reads"

HolderAndrew

Well Known Member
Hello all,

I have also posted on iseries forum but will repeat here - I hope somebody can help! We are on E1 9.1 TR 9.1.5.5 using iseries V7R2 with latest PTFs

If in 5250 sql session we use commitment control (any of *UR, *RR, *CS, *RS) and do an update, for example "update testdta/f03012 set aitxa1 = '205' where aian8 = 12345" then this updated value can be seen immediately within E1 web session (in our JDV910 environment) within P03013 AR master inquiry. If we perform ROLLBACK back in sql session then the E1 P03013 session will see then see the original value when we refresh the inquiry.

Does anybody know how we can prevent the E1 session from seeing uncommitted data - ie. dirty reads?

The f03012 is being journalled with *BOTH images and I have also tried with journaling on the F03012 access paths (F03012_1 etc)

I have looked at JDE.INI, JAS,INI settings and googled around - but haven't been able to understand how to control this.

It seems that despite commitment control being active, and not yet committed, the updates are always immediately visible inside E1.

Our actual production problem is based on this question. We have BSSV running with manual commitment active within order creation MBF - the End Doc is therefore called but the COMMIT is not yet performed. But we see other E1 processes running and selecting the F4211 data based on the uncommitted values which is causing a lot of problems.

Any help would be greatly appreciated.

Best regards

Andrew
 
Hi,

after a lot of researching the answer is what we expected - that for DB2/400 you cannot switch off uncommitted reads within E1. Theoretically there is a way in native sql to do this but not from within the middleware.

So the big question now is how to control processes based on data values which may not yet be committed. For example F4211.NXTR might be at '600' in data selection of Process B (which does not use transaction processing) but if ROLLBACK occurs back in Process A then the status will return back to '530' (for example) but the update actions in process B may have already occurred on many other tables - causing data integrity issues.

F00095 can be used to basically block a process if it finds an order reservation - but then you will need to wait X seconds before continuing. It seems as more processes (Order entry, ship confirm, BO release) use transaction processing the likelihood of issues caused by uncommitted reads increases. So we are trying to figure out what other sites are doing. When you have >400k order lines a day with dozens of just-in-time processes, then dirty reads can be an increasing risk to services.

Best regards

Andrew
 
Back
Top