Question

I’m starting to investigate on using SQLite. What I would like to do (among other things) is implementing some kind of checkout semantic. I.e if one sql connection makes a checkout lock on one column or row doesn’t matter. I would like no other connections to be allowed for reading or modifying that data until the first connection releases the lock OR the first connection closes/application crach etc..

Would this be implementable in SQLite?

/Thanks in advance!

Answer 1

Databases in general don’t really support checkout semantics. The databases guarantee transaction isolation, but since they don’t guarantee that transaction succeeds, they can let another transaction proceed with old version of data that another transaction just modified (and didn’t commit yet) and if the transactions actually become non-serializable, just roll one back. Even if they do use locking, they still don’t support it explicitly. You read the row, it becomes read-locked and if you write it, it becomes write-locked, but you don’t have any control over it.

Sqlite in particular locks whole database when you start writing in a transaction unless in WAL mode. You can force the lock by starting the transaction with begin immediate instead of just begin. In WAL mode however it supports some kind of concurrency. Unfortunately I don’t know the exact mode.

In any case, you’ll probably end up having to implement the checkout semantics yourself. Or do without it, because checkout semantics is quite complicated by having to deal with stale checkouts.