Jan,
> ... plus that the catch-nesting automatically represents the
> subtransaction nesting. I can't really see any reason why those two
> should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints and exception handling
should be kept separate. Consider the following two examples:
savepoint a
spi calls
savepoint b
spi calls
savepoint c
spi calls
switch(some test)
{case 1: rollback b; commit a; break; case 2: rollback c; commit a; break; case 3: rollback a; break;
default: commit a;
}
or nested try/catch where the catch doesn't access the database:
foo()
{ try { spi calls; } catch { set some status; re-throw; }
}
and some other place in the code:
savepoint a try { spi calls; for(i = 0; i < 100; ++i) foo(); commit a; } catch { rollback a;
}
If "normal" savepoint hanling is disabled here in favor of your
suggestion, you will get 101 subtransations although only 1 is relevant.
I still think that the concept of savepoints is fairly easy to
understand. Using it together with exception handling is a common and
well known concept and we can make it even more so by providing good
documentation and examples.
Regards,
Thomas Hallgren
