sqlite transition from transactions to savepoints

Question

My SQLite-based application currently uses transactions - both for being able to rollback and for improving performance. I'm considering replacing all transactions with savepoints. The reason is that the application is multi-threaded (yes, sqlite is configured to be thread-safe), and in some cases a transaction might get started by two threads in the same time (on the same db).

1. It there a reason NOT to do it?
2. Are there any pitfalls I need to be aware of?
3. Do I just replace BEGIN, COMMIT, ROLLBACK with SAVEPOINT xyz, RELEASE SAVEPOINT xyz, ROLLBACK TO SAVEPOINT xyz?

Answer 1

    It there a reason NOT to do it?

Yes. It won't solve any of the problems that you outlined. Save points are primarily used to be able to do partial rollbacks of data. The outer transaction or savepoint is what actually is committed. Nothing is really fully saved until that outermost savepoint is released thus updating the DB. You are right back back to the same problem that you have with standard transactions.

    Are there any pitfalls I need to be aware of?

Yes. Transactions or savepoints in a multithreaded application can deadlock fairly easily if you are update the same data in two different threads which I assume is the heart of the matter. There is no difference between the two in this regard. You should be aware of what you are updating in each thread and synchronize accordingly.

In short, unless you have the need to do partial transaction rollback, savepoints really wont give you much (other than the fact that they are named.)

There is no silver bullet here. It sounds like you need to do a serious analyses of your application and the data that may be updated in multiple threads and add some synchronization in you application if needed.