Project

General

Profile

Bug #6744

rollback when there are catch/finally blocks opening their own transactions

Added by Constantin Asofiei almost 4 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#2 Updated by Constantin Asofiei almost 4 years ago

I'm seeing an abend with a customer app where a savepoint is no longer valid (when trying to rollback-/commit-). I've been trying to duplicate it, but I haven't been lucky - it seems to happen only when a legacy exception is being thrown and there are catch/finally blocks which calls code which opens another transaction; for example, this:

block-level on error undo, throw.

def temp-table tt1 field f1 as int.

procedure proc1.
   do:
      create tt1.
      tt1.f1 = 11.

      undo, throw new Progress.Lang.AppError("problem!").
   end.
end.

procedure proc2.
   do transaction:
      create tt1.
      tt1.f1 = 22.
      undo, leave.
   end.
end.

procedure proc0.
   run proc1.
   finally:
      run proc2.
   end.
end.

do transaction:
   do transaction:
      create tt1.
      tt1.f1 = 33.
   end.
   run proc0.
   catch ex as progress.lang.error:
      message ex.
   end.
end.

for each tt1:
   message tt1.f1.
end.

it finds a record in FWD (the '33' record), but only when the catch ex as progress.lang.error: code exists.

It may be also related to the fact that we have in BlockManager code like this:

               catch (LegacyErrorException lex)
               {
                  throw lex;
               }

which just re-throws the exception without doing any rollback for the current block.

I've been trying to add code to track how savepoints are created, released, rolledback and committed, but I don't understand really how these are supposed to work. For example, in this testcases:
  • there is a savepoint S1 created before validation
  • during validation, lazilySetSavepoints is being called, it creates a new savepoint S2 at a block, but the savepoint S1 at the validation gets rolledback/committed. It doesn't look write to me to keep savepoint S2 at the block.

#3 Updated by Alexandru Lungu over 1 year ago

Artur, is this task related to your recent work on FINALLY blocks and transaction scoping?

#4 Updated by Artur Școlnic over 1 year ago

On the first look, it seems related.

Also available in: Atom PDF