Kbase P114934: Transaction backout taking long time on 10.1A, application has many nested blocks with ON ERROR UNDO
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Verified
SYMPTOM(s):
Transaction backout taking long time.
Transaction does not make many updates to the database.
There is a disproportionately large amount of before-image activity from the client while the transaction is being undone.
Transaction contains many levels of nested subtransactions (around 10, or more).
Database changes are done mostly in the more deeply-nested subtransactions.
Each 4GL block that starts a subtransaction has the clause "ON UNDO, RETURN ERROR".
FACT(s) (Environment):
OpenEdge 10.1A
All Supported Operating Systems
CHANGE:
Migrated from version 9 or from 10.0x to 10.1A.
CAUSE:
Bug# OE00127757
CAUSE:
When a 4GL clients undoes a transaction, it must do the same operations carried out during forward processing, but with an inverted sign: if a record was created during forward processing, it must be deleted during transaction backout.
Therefore, transaction backout generates some new database activity; for crash recovery to work correctly, this new database activity must be recorded in the before-image file as well, just as it happens with forward processing. When undoing a transaction, a client will end up writing twice as many before-image notes as with forward processing.
Before the introduction of savepoints in OpenEdge 10.1A, the undoing of a subtransaction was handled and optimized via the local before-image file, which led to the net result that only just about as many notes would be written during transaction rollback as they were written during forward processing.
FIX:
1. Upgrade to 10.1B
2. As a workaround, use the -nosavepoint startup option on your client processes [_progres, _proapsv, prowin32, etc].
This option restores the pre-10.1A local before-image mechanism.