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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
