2012-08-18 3 views
0

MSDN описывает изоляцию транзакций JET для своего провайдера OLEDB следующим образом:Изоляция транзакций в JET?

Джет поддерживает пять уровней вложенности в сделках. Единственным поддерживаемым режимом для транзакций является Read Committed. Установка меньшего разряда уровней транзакционного разделения означает Read Committed. Установка более высоких уровней приведет к сбою StartTransaction.

Jet поддерживает только однофазную фиксацию.

MSDN описывает Read Committed следующим образом:

Указывает, что общие блокировки удерживаются в то время как данные считываются с избежать грязного чтения, но данные могут быть изменены до конца сделки, что приводит к неповторяемым показаниям или фантомным данным. Этот параметр является стандартом SQL Server.


Мои вопросы:

  1. Что совершают однофазный? Какое это имеет значение для транзакций и изоляции?

  2. Будет ли уровень изоляции Read Committed, как описано выше, подходящим для моих требований here?

  3. Каков наилучший способ достижения изолированности транзакций Serializable с помощью Jet?

ответ

1

По номеру вопроса:

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

  2. Да, если вы проверите условие в самом заявлении UPDATE; иначе у вас могут быть проблемы.

  3. Они, кажется, предполагают, что вы не можете.

Будучи в стороне, я много лет работал консультантом в самых разных условиях. Не раз я был занят, чтобы мигрировать людей с Jet из-за проблем с производительностью. В одном случае простой запрос типа «звезда» выполнялся в течение двух минут, потому что он соединялся с клиентом, а не позволял базе данных это делать.В качестве прямого запроса к базе данных она была второй. В другом случае был отчет, на который потребовалось 72 часа, чтобы пройти через Jet, что заняло 2 минуты при прямом запуске базы данных. Если он обычно работает нормально для вас, вы можете иметь дело с такими ситуациями, используя хранимые процедуры, в которых Jet вызывает боль в производительности.

+0

Сравнивая скорость JET и SQL-сервера, вы обнаружите в качестве общего правила, что значительное количество операций JET будет намного быстрее, чем использование SQL-сервера. SQL-сервер имеет несколько уровней программного обеспечения, файл журнала и уровень транзакции между вашим программным обеспечением и данными. В случае JET вы не используете сервер, вы не используете или не подключаетесь к службе, и в большинстве случаев вы не подключаетесь к данным через какое-либо сокет (сетевое) соединение. В результате вы напрямую используете диск в качестве файла, а результат - МНОГО более высокая производительность, чем SQL-сервер, на значительную сумму –