SQLite3 :: BusyException

Question

Запуск сайта rails прямо сейчас с использованием SQLite3.

Примерно каждые 500 запросов или около того, я получаю

ActiveRecord :: StatementInvalid (SQLite3 :: BusyException: база данных заблокирована: ...

Какой способ исправить это, который будет минимально инвазивным для моего кода?

В настоящее время я использую SQLLite, потому что вы можете хранить БД в системе управления исходным кодом, что делает резервное копирование естественным, и вы можете быстро выдавать изменения. Тем не менее, он явно не настроен для одновременного доступа. Я перейду на MySQL завтра утром.

Answer 1

Попробуйте выполнить следующее, это может помочь:

ActiveRecord::Base.connection.execute("BEGIN TRANSACTION; END;") 

От: Ruby: SQLite3 :: BusyException: база данных заблокирована:

Это может очистить любую транзакцию, удерживающую систему

Answer 2

это часто является последовательной ошибкой нескольких процессов, обращающихся к одной и той же базе данных, т. Е. Если в RubyMine не был установлен флаг «разрешить только один экземпляр»

Answer 3

Я обнаружил тупик на расширении sqlite3 ruby ​​и исправил его здесь: попробуйте и посмотрите, исправит ли это вашу проблему.

    https://github.com/dxj19831029/sqlite3-ruby

Я открыл запрос на получение ответа, ответа от них больше нет.

Во всяком случае, ожидается некоторое занятое исключение, как описано в самом sqlite3.

Имейте в виду с этим условием: sqlite занят

    The presence of a busy handler does not guarantee that it will be invoked when there is 
    lock contention. If SQLite determines that invoking the busy handler could result in a 
    deadlock, it will go ahead and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of 
    invoking the busy handler. Consider a scenario where one process is holding a read lock 
    that it is trying to promote to a reserved lock and a second process is holding a reserved 
    lock that it is trying to promote to an exclusive lock. The first process cannot proceed 
    because it is blocked by the second and the second process cannot proceed because it is 
    blocked by the first. If both processes invoke the busy handlers, neither will make any 
    progress. Therefore, SQLite returns SQLITE_BUSY for the first process, hoping that this 
    will induce the first process to release its read lock and allow the second process to 
    proceed.

Если вы соответствуете этому условию, тайм-аут больше не действителен. Чтобы избежать этого, не помещайте select внутри begin / commit. или используйте эксклюзивную блокировку для начала / фиксации.

Надеюсь, это поможет. :)

Answer 4

Argh - проклятие моего существования за последнюю неделю. Sqlite3 блокирует файл базы данных, когда какой-либо процесс записывает в базу данных. IE любой запрос типа UPDATE / INSERT (также выберите по какой-либо причине count (*)). Тем не менее, он отлично справляется с несколькими операциями чтения.

Итак, я, наконец, достаточно расстроился, чтобы написать собственный код блокировки потоков вокруг вызовов базы данных. Убедившись, что приложение может иметь только один поток записи в базу данных в любой момент, я смог масштабировать до 1000 потоков.

И да, это медленно, как ад. Но это также достаточно быстро и правильно , что является хорошим свойством.

Answer 5

К какой таблице обращаются при обнаружении блокировки?

Есть ли у вас длительные транзакции?

Можете ли вы выяснить, какие запросы еще обрабатывались при обнаружении блокировки?

Answer 6

Я полагаю, что это происходит, когда тайм-аут транзакции. Вы действительно должны использовать «настоящую» базу данных. Что-то вроде морось или MySQL. Любая причина, почему вы предпочитаете SQLite по сравнению с двумя предыдущими вариантами?