Darren Duncan <[EMAIL PROTECTED]> wrote:
The whole point of being implemented as separate transactions rather than "save points" is that any particular block of code or SQL that needs to be atomic doesn't have to special case how it is defined depending on whether it is a main or child transaction
I'd still like some limited notion of a savepoint to be implemented, to support enlisting a SQLite node into a distributed transaction. You see, three-phase distributed commit protocol requires the possibility of a "roll-forward" state. In this state, you have successfully made all the changes to the database, but may still have to explicitly roll back (because some other node has failed). But, if the application crashes at this point and is restarted, it must act as if the transaction was in fact committed - this is referred to as rolling forward.
It shouldn't be difficult to implement, by setting some special flag in the journal file. A programmatic rollback would ignore this flag and proceed as usual. But a recovery procedure would notice the flag and simply delete the journal file without rolling back.
Igor Tandetnik
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
