SQLite Forum

Exclusive write-only lock? (Allow only one process read-write, and multiple read-only)
Login
> Is it possible ... opened only by one process that can modify it, but still allow other processes open it in read-only mode?

Not only is this possible, it's a fairly common use-case, and SQLite is excellent at doing this fast and efficiently on a local file-system and a pretty good solution for a Network file-system[1].

Simply open the DB in the "Writing Process" as normal, and then let every "reader Process" open it with the correct READONLY flag in SQLite API (as Gunther suggested) or if you access it via a Wrapper or Data-Object and connection-string, find and set the correct Read-Only attribute/string/property upon opening it.

To further emphasize what Gunther said - Note that SQLite has NO CONTROL WHATSOEVER over the file other than what you tell it to open it as. If you spawn two "Writer-Processes", SQLite will open both times correctly, and if you start writing from both, SQLite will do it's best to take both inputs (which is not what you want) so you have to manage/block any such possibilities from your application's side. Further to being "unwanted", on a Networked file system, this can even [corrupt the file](https://sqlite.org/howtocorrupt.html) and lose you some data.

Lastly, in the quote above you say:

> ...  an sqlite database (either with rollback journal or in WAL-mode) ...

Note that these are two very different things. In the normal [journaling modes](https://sqlite.org/lockingv3.html#rollback), SQLite will "wait" for writers to finish transactions before readers can read. Only in [WAL mode](https://sqlite.org/wal.html) can you have readers reading existing data [WHILE a writer is writing new data](https://sqlite.org/wal.html#concurrency).  
This makes it possible to actually write-LOCK the DB (at least on a Local file-system) by starting a write-transaction implicitly and keeping it open, with occasional commits/[checkpoints](https://sqlite.org/wal.html#checkpointing) which can be read by readers, but still blocking any other process from writing. However, you still can't control (by just using SQLite) which process gets to the write-lock first.
(Some special options exist here, like reading uncommitted data, but that's another discussion)

These above options are simply touching very lightly on the possibilities. you need to study the documentation quite well before making a decision, and/or specify a lot more accurately what your exact intended use/architecture is, then someone here will be able to give some advice on the best way that SQLite can help do it.



[1] Local File-System means a File-System (and as such: Files) which the same Operating System that is running your process, is directly controlling. If it has to ask another OS for the file data (such as Network files, NAS, etc.) then file-locking feedback is not guaranteed to be accurate and thus general concurrency is not workable, but single-writer DBs should work fine (in my experience, at least).