Samuel R. Neff wrote:
I personally would see value in supporting quasi-nested transactions where
they are nested in name only--increment decrement a counter and commit on
last commit, rollback entire transaction on first rollback. This would have
the advantage that the library would support issuing multiple BEGIN
TRANSACTION statements without error.
I often find in my code that I have library routines that want to run in a
transaction and can run in their own transaction or join an existing
transaction. In SQLite I would need to have extra logic in place to detect
the transaction state and only run in a transaction if one is not already in
place.
I say "would" because the SQLite.NET [1] wrapper provides nested
transactions as a counter already, on top of the SQLite library (as long as
I use the connection.BeginTransaction() method and don't issue an explicit
BEGIN TRANSACTION call myself).
Samuel,
I do the same thing in my wrapper for the same reason. I think this is
by far the most common case where users see a need for nested
transactions. It decouples subroutines from their calling context. This
form of nested transactions is exactly what several other database
engines provide. It is simple to implement and does what the vast
majority of users need.
I'm sure there are circumstances that can tolerate only some of the
statements in a transaction being executed, but for most applications a
transaction is *all or nothing*. They don't want to execute the first
and last statement but skip the middle two. It seems to me any
application that can tolerate some statements in a transaction not
executing could factor those statements out into a separate transaction.
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
