Transactions and Undos. Novel - Forum - OpenEdge RDBMS - Progress Community

Transactions and Undos. Novel

 Forum

Transactions and Undos. Novel

  • I have investigated a bit father the large transaction above. As usually the answers raise new questions. Undo phase is now looking even more “mystical”.

    First of all, the program that updated the database was run inside a block with transaction property. So in fact it was a sub-transaction from the session’s point of view. It’s an important note!

    The transaction was very large (the size of its scan is 40 GB). So I traced the history only for 3 blocks updated by transaction:
    A. the block updated at the beginning of the transaction. Really it’s a second block updated by transaction;
    B. the block updated in the middle of the transaction. Really it’s a block updated just before the session received the HANGUP signal. It does not turn out to matter;
    C. the block updated at the end of FWD phase;
    O. The changes of object block will be mentioned as a part of the changes of RM chain.

    During the FWD phase of transaction the blocks are updated in the following order: A -> B -> C.
    During the UNDO of phase of (sub-) transaction the expected order: C -> B -> A.

    The history of the block updates:

    11:54:48   code = RL_TBGN =================================================================================
    
    11:54:49 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 1 to 64 (64 updates)
    11:54:49 O code = RL_BKFRM  area = 11   dbkey = 131072       update counter = 61007108
    11:54:49 A code = RL_BKFRB  area = 11   dbkey = 9986286912   update counter = 65
    
    12:01:36 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 1 to 64 (64 updates)
    12:01:36 O code = RL_BKFRM  area = 11   dbkey = 131072       update counter = 61014341
    12:01:36 B code = RL_BKFRB  area = 11   dbkey = 9987806848   update counter = 65
    
    13:26:46 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 1 to 21 (21 updates)
    
    13:26:46   Sub-transaction was interrupted (by END-KEY?) ==================================================
    
    13:26:46 C code = RL_RMDEL  area = 11   dbkey = 9976954368   update counter = 22 to 62 by 2 (21 updates)
    13:26:46 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 23 to 63 by 2 (21 updates)
    
    14:11:11 B code = RL_RMDEL  area = 11   dbkey = 9987806848   update counter = 66, 69 to 193 by 2 (64 updates)
    14:11:11 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 67, 70 to 194 by 2 (64 updates)
    14:11:11 B code = RL_BKBBOT area = 11   dbkey = 9987806848   update counter = 68
    14:11:11 Z code = RL_BKBBOT area = 11   dbkey = 9987806784   update counter = 68
    14:11:11 O code = RL_BKMBOT area = 11   dbkey = 131072       update counter = 61070135
    14:11:11 B code = RL_BK2EB  area = 11   dbkey = 9987806848   update counter = 195
    
    14:22:05 A code = RL_RMDEL  area = 11   dbkey = 9986286912   update counter = 66, 69 to 189 by 2 (62 updates)
    14:22:05 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 67, 70 to 190 by 2 (62 updates)
    14:22:05 A code = RL_BKBBOT area = 11   dbkey = 9986286912   update counter = 68
    14:22:05 A code = RL_BK2EB  area = 11   dbkey = 9986286912   update counter = 191
    
    14:27:02 A code = RL_RMDEL  area = 11   dbkey = 9986286912   update counter = 192 to 314 by 2 (62 updates)
    14:27:02 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 193 to 315 by 2 (62 updates)
    
    14:29:27 B code = RL_RMDEL  area = 11   dbkey = 9987806848   update counter = 196 to 322 by 2 (64 updates)
    14:29:27 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 197 to 323 by 2 (64 updates)
    
    14:29:28   HANGUP signal received (562) ===================================================================
    
    15:33:20 C code = RL_RMDEL  area = 11   dbkey = 9976954368   update counter = 64 to 104 by 2 (21 updates)
    15:33:20 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 65 to 105 by 2 (21 updates)
    
    15:33:20 C code = RL_RMDEL  area = 11   dbkey = 9976954368   update counter = 106 to 146 by 2 (21 updates)
    15:33:20 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 107 to 147 by 2 (21 updates)
    
    16:02:48 B code = RL_RMDEL  area = 11   dbkey = 9987806848   update counter = 324 to 450 by 2 (64 updates)
    16:02:48 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 325 to 451 by 2 (64 updates)
    
    16:09:16 A code = RL_RMDEL  area = 11   dbkey = 9986286912   update counter = 316 to 438 by 2 (62 updates)
    16:09:16 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 317 to 439 by 2 (62 updates)
    
    16:09:16   Begin transaction backout. (2252) ==============================================================
    
    16:09:16 A code = RL_RMDEL  area = 11   dbkey = 9986286912   update counter = 440 to 562 by 2 (62 updates)
    16:09:16 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 441 to 563 by 2 (62 updates)
    
    16:10:46 B code = RL_RMDEL  area = 11   dbkey = 9987806848   update counter = 452 to 578 by 2 (64 updates)
    16:10:46 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 453 to 579 by 2 (64 updates)
    
    17:09:39 C code = RL_RMDEL  area = 11   dbkey = 9976954368   update counter = 256 to 296 by 2 (21 updates)
    17:09:39 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 257 to 297 by 2 (21 updates)
    
    17:56:39 A code = RL_RMCHG  area = 11   dbkey = 9986286912   update counter = 564 to 625 by 2 (62 updates)
    
    17:59:41 B code = RL_RMCHG  area = 11   dbkey = 9987806848   update counter = 580 to 643 (64 updates)
    
    19:02:58 C code = RL_RMCHG  area = 11   dbkey = 9976954368   update counter = 298 to 318 by 2 (21 updates)
    
    19:02:58 C code = RL_RMDEL  area = 11   dbkey = 9976954368   update counter = 319 to 359 by 2 (21 updates)
    19:02:58 C code = RL_RMCR   area = 11   dbkey = 9976954368   update counter = 320 to 360 by 2 (21 updates)
    
    20:02:18 B code = RL_RMDEL  area = 11   dbkey = 9987806848   update counter = 644 to 770 by 2 (64 updates)
    20:02:18 B code = RL_RMCR   area = 11   dbkey = 9987806848   update counter = 645 to 771 by 2 (64 updates)
    
    20:11:06 A code = RL_RMDEL  area = 11   dbkey = 9986286912   update counter = 626 to 748 by 2 (62 updates)
    20:11:06 A code = RL_RMCR   area = 11   dbkey = 9986286912   update counter = 627 to 749 by 2 (62 updates)
    
    20:11:07   code = RL_TEND =================================================================================

    Initial interruption of sub-transaction was initiated by ABL code. As expected the transaction’s state stayed unchanged: FWD.

    UNDO of sub-transaction was handled via the local before-image file: the session did not read BI file at this phase. It’s not expected because the session did not use the -nosavepoint parameter (transaction used the RL_TMSAVE notes).
    Since 34:25 after interruption promon shown:

    02/22/19        Status: Active Transactions by user number for all tenants
    14:01:11
      Usr:Ten   Name      Domain     Type       Login time     Tx start time  Trans id  BI RReads BI RWrites Trans State
      950       XXXXXXXX       0     SELF/ABL   02/21/19 12:59 02/22/19 11:54 715548686         0   35583963 Active  FWD

    What ABL events can initiate such type of UNDO?

    During UNDO of sub-transaction the blocks were updated in the following order:
    1. C -> B -> A -> 2. A -> B -> C -> 3. C -> B -> A
    In other words it was:
    1. UNDO of FWD phase
    2. UNDO of UNDO # 1
    3. UNDO of UNDO # 2
    Why we got 3 phases of UNDO?

    Transaction has created 64 records in the block A. During UNDO phases of sub-transaction as well as during UNDO of the whole transaction only 62 slots were processed in this block: the records were deleted and replaced by placeholders and vice versa. Why two slots were missed?

    As expected the reaction on HANGUP signal was postponed until the end of sub-transaction UNDO.

    UNDO of the whole transaction did not ignore the changes done during UNDO phase but it seems to be the result of using LBI file during UNDO phase. Otherwise the transaction would be completed immediately after the end of sub-transaction UNDO.

    More over the order of changes are not mirroring the changes on the previous phases:
    UNDO of the whole transaction updated the blocks in the order: A -> B -> C

    Then unexpected we got the RL_RMCHG notes for each slot in the blocks in the order: A -> B -> C. Note that there were no RL_RMCHG notes on all preceding phases. What are they doing? And why the order of these changes is not reverse to the previous notes?

    And finally the records were deleted and replaced by the placeholder in the expected order: C -> B -> A

  • simple.

    when the 4GL undoes a subtransaction using the LBI file, the database knows nothing about it. to the datbase, it just looks like more forward processing.

    block were updated a->b->c, followed by subtransaction undo of c->b->a so now the order of forward processing changes seen by the database is

    a->b->c->c->b->a

    then those changes are undone in reverse order

    a->b->c->c->b->a

  • > when the 4GL undoes a subtransaction using the LBI file

    But UNDO uses the LBI file only when a session was started with the -nosavepoint option. At least my tests did not find other scenarios.

  • you are correct.

    when the database rolls back a savepoint, it then forgets about it so it has the same effect as the lbi driven rollback. it could (in theory and in practice) use another kind of jump note to skip over all the do and undo operations in the savepoint but currently i don’t believe it does that.

  • In my tests I used the UNDO statement to roll back a sub-transaction. UNDO of transaction read the notes left by the changes before and after the sub-transaction but totally skipped all notes related to the undone sub-transaction. It was the same way even in client-server mode.

    Gus, as you wrote earlier there are many types of UNDOs. I guess in this case we got a type of undo that ignores the save points. Could it be possible? I don't know what was an event that triggered the undo.