Доброго дня!

Может быть в форум по PHP надо было постить, но мне кажется, что недопонимаю особенности SQLite.

Для малюсенького проектика SQLite выбрал из-за удобства переносимости и малого (три таблицы, суммарно окло 1500) количества записей. Сразу скажу, что это мой первый опыт разработки с использованием данной СУБД.

В проекте есть скрипт (PHP, подключается к базе через PDO), запущенный в консоли постоянно. Значительную часть времени он "спит", просыпаясь каждые 5...15 минут для работы на 2...3 минуты и делает SELECT/INSERT/UPDATE - за весь цикл порядка 10 запросов. Есть еще небольшая веб-морда (тоже PHP+PDO), через которую правятся две таблицы из трех. По сути, это получается два клиентских подключения к БД. На данный момент использую SQLite версии 3.7.15.2, PHP 5.3.18, если это имеет значение.

Суть проблемы изначально была в блокировке БД. Если на момент сохранения данных из веб-интерфейса работает консольный скрипт, тогда скрипт веб-морды срубится по таймауту. Видимо, ждет снятия блокировки. И, наоборот, если недавно было сохранение данных из вебморды, то консольный скрипт вываливает ексепшн " SQLSTATE[HY000]: General error: 5 database is locked " при отработке запроса в транзакции. Пытаюсь обеспечить более-менее приличную "отзывчивость" скрипта веб-интерфейса. Пробовал выполнить запросы " PRAGMA journal_mode=WAL;PRAGMA synchronous = NORMAL; ", как советуют на форумах - получилось. Частично. Скрипт веб-интерфейса стал отрабатывать нормально. Однако, в консольном по-прежнему некоторое время ексепшн после обращения из веб-скрипта...

Почему получилась такая "несимметрия", куда смотреть, на что обратить внимание...? Структура скриптов в части UPDATE на данный момент практически одинакова в обоих случаях и выглядит примерно так:

Есть еще SELECT'ы-одиночки без транзакций.

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

Заранее благодарю.

PS: Предложения переехать на мускуль/постгри/прочее не годятся.

White OwlДве-три минуты это ого-го-го и ой-ёй-ёй.Не совсем так :) Ну, кроме запросов к БД скрипт еще и основной работой занят. Из базы берет задание, долго обрабатывает, пишет в базу результат, берет следующее. Обработал так пяток заданий - уснул минут на 15 до следующей порции. Таков основной цикл.
White Owlvkle Есть еще небольшая веб-морда (тоже PHP+PDO), через которую правятся две таблицы из трех. По сути, это получается два клиентских подключения к БД. На данный момент использую SQLite версии 3.7.15.2, PHP 5.3.18, если это имеет значение.Если админский скрипт написан на том же PHP что и веб, то нет.В смысле, не имеет значения, или не два подключения?

White OwlРви связь в промежутке.Благодарю за подробное описание. В общем то, прихожу именно к этому выводу. Видимо, другие способы в моем случае не очень то приемлемы для надежной работы.

И, вот еще вопросик.
Правильно ли я думаю, что если типовое максимальное время работы скрипта от коннекта до дисконнекта будет, скажем, пол-секунды, то одной-двух секунд для sqlite_busy_timeout , которое устанавливаю сразу просле коннекта, будет вполне достаточно? Как я понял, по дефолту PHP ставит таймаут в 60 секунд, судя по этой доке . Для моего случая с PDO то ли искал плохо, то ли оно идентично... Смысл такой, чтоб если при запросе от какой-то стороны возникнут какие-то коллизии, то поймать ексепшн и быстренько отдать сообщение об ошибке (а не ждать всю минуту). Или у SQLite могут быть какие-то ощутимые внутренние потребности в исключительной блокировке?