>> Про 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 тоже интенсивно пишет в базу, не получится ли ситуация вечного перечитывания базы с диска при каждом запросе ?
Оптимизация такой ситуации сводится к разносу таблиц А и Б по разным базам ? Но если процессы конкурируют за доступ к одной таблице ?
