Кто не в курсе запись в SQLite работает только эксклюзивная, и только чтение из sqlite-базы можно паралельно выполнять.

Кто как решает проблему?

Есть 2 подхода:
1) Retry Pattern, например http://www.thepollyproject.org/
Он так же может использоваться для борьбы с dead-lock-ами в нормальных СУДБ. Ну неплохо как бы, но менее надежно чем второй способ.

2)
Заворачивать блоки чтения в ReadWriterLock на чтение, и блоки кода с записью в БД в ReadWriterLock на запись.
Работает надежно по сравнению с 1м, но для обычных СУДБ не нужно.

Для второго подхода что можно подсмотреть готовое?. Приходит на ум только такой класс MyLock

using(var lockPolicy = MyLock.Readonly)
{
   /// читаем из базы
   if (needWrite)
   {
      lockPolicy.UpgradeToWriting();
      // пишем в БД
   }
}

...

using(MyLock.ReadWrite)
{
   /// пишем в базу
}

Интересует как бы это завернуть в DI майкрософтовский. Если это имеет смысл.

Здравствуйте, VladCore, Вы писали:

VC>Кто не в курсе запись в SQLite работает только эксклюзивная, и только чтение из sqlite-базы можно паралельно выполнять.
да, писатель только один, читателей можно одновременно несколько (даже если есть активный писатель — режим WAL).

VC>Кто как решает проблему?
то что в один момент времени писатель может быть только один — никак не обойти, то есть никак не решить.
можно только действовать в соотвествии с этой особенностью.
стараться делать короткие пишущие транзакции.
по возможности упаковывать серию модификацию в одну транзакцию на БД.


VC>Есть 2 подхода:
VC>1) Retry Pattern, например http://www.thepollyproject.org/
VC>Он так же может использоваться для борьбы с dead-lock-ами в нормальных СУДБ. Ну неплохо как бы, но менее надежно чем второй способ.
а зачем делать retry, когда можно сразу выставить адекватный период ожидания захвата базы на чтение в самом sqlite?


VC>2)
VC>Заворачивать блоки чтения в ReadWriterLock на чтение, и блоки кода с записью в БД в ReadWriterLock на запись.
VC>Работает надежно по сравнению с 1м, но для обычных СУДБ не нужно.
читатели не мешают писателю и писатель не мешает читателям, зачем ещё блокировки на чтение?

оба способа это не решение проблемы одного писателя (это в sqlite не решается в принципе). это про что делать если писатель не дождался освобождения базы другим писателем.
и варианты тут такие:
1. ещё разок попробывать. но тогда проще выставить сразу адекватный интервал ожидания, и sqlite сам внутри и будет ждать и когда дождётся — выполнит транзакцию.
2. раз не дождались, то всё. выдать юзеру сообщение типа — база занята, попробуйте позже ещё раз.
так как это может быть действительно какая-то долго играющая транзакция и уже не стоит всё время долбить базу повторами и заставлять юзера ждать.

Здравствуйте, VladCore, Вы писали:

VC>Кто не в курсе запись в SQLite работает только эксклюзивная, и только чтение из sqlite-базы можно паралельно выполнять.

VC>Кто как решает проблему?

А в чем проблема выставить serializable isolation level.

Здравствуйте, MadHuman, Вы писали:

VC>>Он так же может использоваться для борьбы с dead-lock-ами в нормальных СУДБ. Ну неплохо как бы, но менее надежно чем второй способ.
MH>а зачем делать retry, когда можно сразу выставить адекватный период ожидания захвата базы на чтение в самом sqlite?

Лол. deadlock в нормальных СУДБ сразу выбрасывается.

MH>читатели не мешают писателю и писатель не мешает читателям, зачем ещё блокировки на чтение?

Что у вас там за каша в голове? Это в нормальных СУДБ только не "мешают" (на самом деле "мешают" и в блокирующих транзакциях и в транзакциях работающтх на snapshot-ах). В sqlite это не так.

MH>оба способа это не решение проблемы одного писателя (это в sqlite не решается в принципе). это про что делать если писатель не дождался освобождения базы другим писателем.
MH>и варианты тут такие:
MH>1. ещё разок попробывать.

Лол. ты изобрел retry pattern

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, VladCore, Вы писали:

VC>>Кто не в курсе запись в SQLite работает только эксклюзивная, и только чтение из sqlite-базы можно паралельно выполнять.

VC>>Кто как решает проблему?

S>А в чем проблема выставить serializable isolation level.

Для всего? Ну тогда и читатели будут висеть в ожидании других читателей.

И чем это лучше ReaderWriterLock на стороне C#?

Для iOS/Android оно только годится — там всего один пользователь.
А для серверов — нет. Оно конечно стремно выглядит embedded базу юзать на сервере, но TeamCity и Grafana прекрасно справляются

Здравствуйте, VladCore, Вы писали:

VC>Кто не в курсе запись в SQLite работает только эксклюзивная, и только чтение из sqlite-базы можно паралельно выполнять.

VC>Кто как решает проблему?

А просто установить SQLiteConnection.BusyTimeout почему не хочешь?

Здравствуйте, VladCore, Вы писали:

VC>Что у вас там за каша в голове? Это в нормальных СУДБ только не "мешают" (на самом деле "мешают" и в блокирующих транзакциях и в транзакциях работающтх на snapshot-ах). В sqlite это не так.

По идее для WAL это вполне себе так.

Здравствуйте, VladCore, Вы писали:

VC>И чем это лучше ReaderWriterLock на стороне C#?

Вы неверняка используете ORM, в котором есть драйвер для sqlite, который уже делате lock. Зачем еще один. Кстати, sqlite помимо serializable поддерживает read commited.
С ним будет пошустрее.

VC>Для iOS/Android оно только годится — там всего один пользователь.
VC>А для серверов — нет. Оно конечно стремно выглядит embedded базу юзать на сервере, но TeamCity и Grafana прекрасно справляются

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

Здравствуйте, m2l, Вы писали:

m2l>А просто установить SQLiteConnection.BusyTimeout почему не хочешь?

Потому что. Кстати в microsoft сборке sqlite, хорошей сборке, BusyTimeout можно только pragma-директивой установить.

Здравствуйте, Sharov, Вы писали:

S>Вы неверняка используете ORM, в котором есть драйвер для sqlite, который уже делате lock.

А в каких ORM есть клиентский Lock? блокировки есть в самой реализации sqlite, вот чтоб на них не нарваться и мог бы ReaderWriterLock из .net это обойти

VC>>А для серверов — нет. Оно конечно стремно выглядит embedded базу юзать на сервере, но TeamCity и Grafana прекрасно справляются

S>А использую на сервере, правда при совсем опереточной и даже менее нагрузке. Но в интеграционных тестах вполне нормально работает при десяти писателях,
S>и кучи читателях.

Прикольно. Но если доступ писателей сериализуется то какая разница 10 писателей или 10 тысяч?

Здравствуйте, VladCore, Вы писали:

VC>Здравствуйте, Sharov, Вы писали:

S>>Вы неверняка используете ORM, в котором есть драйвер для sqlite, который уже делате lock.

VC>А в каких ORM есть клиентский Lock? блокировки есть в самой реализации sqlite, вот чтоб на них не нарваться и мог бы ReaderWriterLock из .net это обойти

Что значит реализация -- самого sqlite на C или драйвер на .net? Т.е. в любом случае будет двойной лок, у себя и там.


VC>Прикольно. Но если доступ писателей сериализуется то какая разница 10 писателей или 10 тысяч?

У меня read commited, соотв. писак может быть множество.

Здравствуйте, Sharov, Вы писали:

S>>>Вы неверняка используете ORM, в котором есть драйвер для sqlite, который уже делате lock.

VC>>А в каких ORM есть клиентский Lock? блокировки есть в самой реализации sqlite, вот чтоб на них не нарваться и мог бы ReaderWriterLock из .net это обойти

S>Что значит реализация -- самого sqlite на C или драйвер на .net? Т.е. в любом случае будет двойной лок, у себя и там.

А в каких ORM есть клиентский Lock? блокировки есть в самой реализации sqlite. В Core 2.2 это майкрсофтовская нативная сборка — libe_sqlite.so и e_sqlite.dll. В Core 3.0 тоже, но там собрана sqlite 3.26 версия, а в 2.2 — 3.22. Раньше были и другие реализации sqlite, я даже помню был sqlite полностью на managed code лол. но я про "встроенную" в .core

VC>>Прикольно. Но если доступ писателей сериализуется то какая разница 10 писателей или 10 тысяч?

S>У меня read commited, соотв. писак может быть множество.

Ты не понял. По диазйну sqlite, в sqlite пишущяя транзакция может быть только одна в любой момент времени. и она всегда serializable.

Здравствуйте, VladCore, Вы писали:


S>>У меня read commited, соотв. писак может быть множество.

VC>Ты не понял. По диазйну sqlite, в sqlite пишущяя транзакция может быть только одна в любой момент времени. и она всегда serializable.

Да, неправ. Мне почему-то казалось, что при записи в разные страницы (можно сказать таблицы) возможно параллельная запись.

EXCLUSIVE An EXCLUSIVE lock is needed in order to write to the database file. Only one EXCLUSIVE lock is allowed on the file and no other locks of any kind are allowed to coexist with an EXCLUSIVE lock. In order to maximize concurrency, SQLite works to minimize the amount of time that EXCLUSIVE locks are held.

https://www.sqlite.org/lockingv3.html