When an exception is thrown during commit() it will execute a rollback cmd on the database

[irgendwienet]

see issue #236

[oysteinkrog]

Hmm ok, so you want the library to automatically handle rollback, which I think is reasonable.
However, I think the code already does this...
The Commit() method is called from RunInTransaction..() where rollback is already handled the way you propose.
IMO the Commit() method should not be changed, it's there so that people can implement their own commit/rollback logic.

[irgendwienet]

I see your point and actually I'm implementing (more or less) my own commit/rollback logic. Maybe I could wrap it in RunInTransaction() but I'm not sure.
For my application I have to research the difference between transaction and savepoints uses in RunInTransactions().

On the other hand: one cannot implement his own commit/rollback logic using the Commit() and Rollback() methods.
Before changing the SQLite.net library I tried so in my applications code. I did database manipulation and Commit() in an try-block and in the catch-block I wanted to use Rollback(). But Rollback() won't work after broken Commit(). Execute("rollback") works after a broken Commit() but that is not the level one should use with SQLite.net.

Why can't I use Rollback()?:
Commit() uses the Interlock.Exchange() on _transactionDepth an sets its value to 0 nevertheless if the commit works or fails (actually it is set to 0 before the commit).
Rollback() checks the same transactionDepth field and in the catch-block after a broken Commit() _transactionDepth will always be 0 so the actual Execute("rollback") will never be executed.