Вопрос: Я в настоящее время храню данные приложения ASP.net в файлах XML.
Теперь проблема в том, что у меня асинхронные операции, что означает, что я столкнулся с проблемой одновременного доступа на запись в файле XML...
Теперь я рассматриваю возможность перехода на встроенную базу данных для решения проблемы. В настоящее время я рассматриваю SQlite и встраиваемый Firebird.
Я не уверен, однако, если SQlite или Firebird могут обрабатывать несколько одновременных возможностей записи.
И я, конечно же, не хочу повторять ту же проблему.
Кто-нибудь знает?
SQlite, безусловно, лучше известен, но какой из них лучше - SQlite или Firebird? Я, как правило, говорю Firebird, но я действительно не знаю.
Нет отзывов MS-Access или MS-SQL-express, пожалуйста, я нормальный человек.
Я буду выбирать Firebird по многим причинам и для этого тоже
Хотя это транзакционный, SQLite не поддерживает одновременную транзакций, поэтому, если ваш встроенный приложение требует двух или более соединения, они должны быть сериализованы. Встроенная база данных Firebird просто обновить до полностью общего базы данных - просто измените общий библиотека.
Возможно, вы также можете проверить this
SQLITE может быть настроен на грамотное управление одновременной записью в большинстве ситуаций. Случается, что когда один поток или процесс начинает запись в db, файл заблокирован. Когда вторая попытка записи и обнаружит блокировку, она возвращается на короткое время, прежде чем повторять запись, пока она не завершится или не закончится. Тайм-аут настраивается, но в остальном все это происходит, если код приложения не должен делать ничего особенного, кроме включения опции, например:
// set SQLite to wait and retry for up to 100ms if database locked
sqlite3_busy_timeout( db, 100 );
Все это работает очень хорошо и без каких-либо затруднений, за исключением двух обстоятельств:
Если приложение делает много записей, скажем, тысяч вставок, все в одной транзакции, тогда база данных будет заблокирована в течение значительного периода времени и может вызвать проблемы для любого другого приложения, пытающегося написать. Решение состоит в том, чтобы разбить такие большие записи на отдельные транзакции, чтобы другие приложения могли получить доступ к базе данных.
Если база данных разделяется различными процессами, запущенными на разных компьютерах, разделяйте сетевой диск. Многие операционные системы имеют ошибки в сетевых жестких дисках, которые делают блокировку файлов ненадежными. На это нет ответа. Если вам нужно разделить db на сетевом диске, вам нужен другой движок базы данных, такой как MySQL.
У меня нет опыта работы с Firebird. Я использовал SQLITE в таких ситуациях для многих приложений в течение нескольких лет.
Вы заглянули в Berkeley DB с поддержкой SQLite API для SQL?
Похоже, SQLite будет хорошо подходить. Мы используем SQLite в ряде производственных приложений, он поддерживает, на самом деле, он предпочитает транзакции, которые идут долгий путь к обработке concurrency.
Я добавил бы # 3 в список из вышеописанной ravenspoint: если у вас есть большой центр обработки вызовов или центр обработки заказов, скажем, где десятки людей могут одновременно нажать кнопку SAVE, даже если каждый из них обновления или вставки только одной записи, вы можете столкнуться с проблемами с использованием подхода тайм-аута занятости.
Для сценария №3 идеальным движком SQL, который может сериализоваться, является идеальным; менее идеальный, но работоспособный - это dbms, который может блокировать запись байтового диапазона совместно используемого файла. Но имейте в виду, что даже блокировка записи по байтам будет недостаточной для большого количества одновременных операций записи, когда к концу файла добавляются новые записи, такие как кабуза в конце грузового поезда, так что несколько процессов пытаются в то же время установить блокировку на одном и том же байтовом диапазоне. С другой стороны, схема блокировки записи по байтам в сочетании с ограниченным файловым подходом с хэшей-ключами (например, старая база данных Revelation/OpenInsight для локальных сетей) будет намного превосходить ISAM для этого сценария.