>> Про deadlock в sqlite я уже не раз слышал. ...
>
>Улыбнуло. Где тесты?

Я вам про реальные приложения, а вы мне про синтетические тесты. Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест.

>Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не

В SQLite не может быть конкурирующих запросов по определению, в каждый момент времени только один процесс всегда имеет доступ к файлу с базой и данные между процессами не расшариваются и не кешируются. Остальные ждут своей очереди, если процесс агрессивно работает с базой, все остальные курят и ждут, пример - RT.

>В жестком диске одна головка пишет в один поток - делаете ли
>вывод, что удел жестких дисков - однозадачные системы?

В СУБД подобных MySQL работает диспетчеризация запросов, при обработке текущего запроса есть картина об очереди запросов в целом и данные могут кешироваться в памяти, запросы обслуживаются одновременно. В SQLite такой диспетчеризации нет, каждый процесс может только судить есть лок или нет, если база лочится _целиком_ (локов на строки и таблицы там нет) и надолго. Насколько я понимаю и для SQLite такие диспетчеры есть, но подключаются отдельно как надстройки.

>> Протестируйте, что будет при большом конкурирующем числе одновременных обращений.

Обращений на запись/изменение. Пока транзакция не закроется, лок не освободится, остальные будут ждать, не важно, что они хотят поменять данные в другой таблице, правильно я понимаю ?

Возможно я что-то упускаю из вида, поясните мне поведение SQLite на примере.
Есть два процесса, которые работают с базой - 1 и 2. Есть две таблицы в базе - A и B.

Процесс 1 делает серию последовательных апдейтов базы A, процесс 2 чуть опоздав делает апдейт базы B.

Когда для процесса 2 появится возможность внести изменения, может ли он вклинится между серией последовательных апдейтов процесса 1 или будет вынужден ждать до их окончания (если они идут непрерывным потоком) ?

Если вклинится может (как я понял только после истечения таймаута), то что будет с процессом 1 после внесения изменений в базу процессом 2, ему придется перечитывать состояние базы с диска, кэш ведь протухнет, а о сути изменений добавленных процессом 2 процесс 1 ничего не знает ?

Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация вечного перечитывания базы с диска при каждом запросе ?

Оптимизация такой ситуации сводится к разносу таблиц А и Б по разным базам ? Но если процессы конкурируют за доступ к одной таблице ?