> In both cases, the transaction either commits or rollback occurs. No
> other option is possible at the end of the transaction, but in the first
> style of transaction semantics you get a "mid-way" decision point. This
> only refers to retryable errors, since errors like access rights
> violations and many other system errors aren't retryable. In the example
You seem to ignore the fact, that a lot of errors (and I assume most of
the real world cases, where the appl actually reacts inside a transaction) are
"repared" by these applications by doing something else instead.
Like the application does an insert gets a duplicate key error and does an update
instead. Or it does an insert gets a foreign key constraint violation,
populates the foreign table and does the insert again. Note that this programming
practice is more efficient, than letting the appl check beforehand if the error cases
are seldom.
It seems to me, that leaving all this to the client (which implicitly inserts
savepoints) can never be as efficient as a serverside feature.
Andreas
---------------------------(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
