Использовать блокировку, когда больше пользователей могут писать в файл базы данных .dbf?

Question

К сожалению, мне нужно иметь дело с файлом .dbf или базой данных, если вы хотите, на стороне сервера, и у меня есть один вопрос. Поскольку .dbf находится на стороне сервера, больше пользователей могут получить к нему доступ (чтение и запись, я использую C # и OdbcConnection). Должен ли я использовать блокировку всякий раз, когда я делаю вставку / обновление?

---

Я отвечу на свой вопрос, потому что хочу вставить кусок кода. У меня есть базовый класс для простых операций

void ExecuteNonQuery(string sqlStatement)
T ExecuteScalar<T>(string sqlStatement)
List<T> GetDataTable<T>(string sqlStatement) where T:new()

public class BaseService
{
        protected void ExecuteNonQuery(string sqlStatement)
        {
            using (OdbcConnection odbconn = new OdbcConnection(ConnectionString))
            {
                odbconn.Open();
                OdbcCommand cmd = new OdbcCommand(sqlStatement, odbconn);
                cmd.ExecuteNonQuery();
            }
        }
}

public class UsersService : BaseService
{
        public void SomeInsert()
        {
            string insertUserString = "Insert Into....";
            ExecuteNonQuery(insertUserString);
            return true;
        }
}

Я не знаю, будет ли это лучшим решением, но эти операции - все, что мне нужно. Я немного запутался, как использовать блокировку здесь.

Answer 1

Вы должны lock в своем собственном коде, когда более одного потока хотят использовать один и тот же OdbcConnection.Но лучше этого избежать.Создайте и используйте соединения, а затем утилизируйте их как можно быстрее.

Вы не можете заблокировать файлы для других пользователей (сеансов).Поставщик Odbc должен синхронизировать эту часть.

Answer 2

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

Если вы ссылаетесь на

1. Какой-то DB Lock, который блокирует файл на диске - Да
2. Thread Locking, который зависит, если параллельный доступ от
   -Потоков из того же процесса, то да, Монитор может добиться цели.
   -Если параллелизм происходит из нескольких процессов в одном блоке, тогда Mutex может работать.
   -Если параллелизм осуществляется с нескольких отдельных серверов, то НИКАКИЕ решения для блокировки потоков не будут работать.

Но вы правы, с файловой базой данных без движка для управления одновременным доступом вам нужно будет осторожно обращаться с одновременным доступом.

Обновление-1:

Для простого сценария single server, single application, **no** web garden вы можете написать свой слой доступа к данным, чтобы ограничить одновременный доступ к файлам DBF, используя lock (синтаксический сахар для монитора). Но сегодняшнее маленькое веб-приложение превращается во что-то, что нужно масштабировать и масштабировать, тогда ваше решение для блокировки должно развиваться вместе с ним.

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

Answer 3

Я из VFP, и поэтому я знаком с использованием файлов DBF. В действительности при работе с соединениями базового типа, такими как через ODBC, вам нужно применять блокировки к данным, только если вы обновляете более одной таблицы за раз (например, при использовании транзакции в базе данных сервера) или если вы хотите убедитесь, что ваша вставка / обновление не завершится неудачно, потому что другой пользователь применил блокировку (поэтому попытка блокировки будет неудачной, а не попытка изменения данных).