With a Read Committed ODBC connection I'm getting the odd record lock when reading from OpenEdge's Auditing tables (Database user table CRUD operations)...
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Failure getting record lock on a record from table PUB._aud-audit-data.
I understand isolation levels and know that this can be resolved by changing to read uncommitted.
Obviously the main danger in doing this is that dirty reads become a possibility. Dirty reads would definitely cause my solution issues so would be a no-go. But...
Does the very nature of OpenEdge Auditing prevent possible dirty reads of the source records being CRUDed?
here's my thinking behind the question... With my configuration, OpenEdge audit records are created upon completion of CRUD operations against the user tables. I want to make sure that I only read audit records where the user table CRUD operation has committed to the database. I suspect that this is always the case and that the audit records are only created after committal of the user table CRUD transaction. If this is the case then it would only be under exceptional circumstance that the audit records transactions would be rolled back and therefore dirty reads of the audit records are not really a possibility...
Is that feasible? Can anyone clarify the life-cycle of a user transaction followed by an audit transaction in OpenEdge? I assume it is unlikely but possible for the audit transaction to fail, in this case what happens to the original, audited, CRUD operation?