Функция JetBeginTransaction
Применимо к: Windows | Windows Server
Функция JetBeginTransaction
Функция JetBeginTransaction позволяет сеансу ввести транзакцию и создать новую точку сохранения. Эта функция может вызываться несколько раз в одном сеансе для создания дополнительных точек сохранения. Эти точки сохранения можно использовать для выборочного хранения или отмены изменений в состоянии базы данных.
JET_ERR JET_API JetBeginTransaction(
__in JET_SESID sesid
);
Параметры
sesid
Сеанс, используемый для этого вызова.
Возвращаемое значение
Эта функция возвращает тип данных JET_ERR с одним из следующих кодов возврата. Дополнительные сведения о возможных ошибках ESE см. в разделах Ошибки подсистемы расширяемого хранилища и Параметры обработки ошибок.
Код возврата |
Описание |
|---|---|
JET_errSuccess |
Операция выполнена успешно. |
JET_errClientRequestToStopJetService |
Невозможно выполнить операцию, так как все действия экземпляра, связанного с сеансом, прекратились в результате вызова JetStopService. |
JET_errInstanceUnavailable |
Невозможно выполнить операцию, так как экземпляр, связанный с сеансом, столкнулся с неустранимой ошибкой, требующей отмены доступа ко всем данным для защиты целостности этих данных. Эта ошибка будет возвращена только в Windows XP и более поздних выпусках. |
JET_errNotInitialized |
Невозможно выполнить операцию, так как экземпляр, связанный с сеансом, еще не инициализирован. |
JET_errRestoreInProgress |
Невозможно выполнить операцию, так как операция восстановления выполняется в экземпляре, связанном с сеансом. |
JET_errSessionSharingViolation |
Один и тот же сеанс нельзя использовать одновременно для нескольких потоков. Эта ошибка будет возвращена только в Windows XP и более поздних выпусках. |
JET_errTermInProgress |
Невозможно выполнить операцию, так как экземпляр, связанный с сеансом, завершает работу. |
JET_errTransTooDeep |
Не удается запустить новую транзакцию, так как сеанс уже находится на максимальной глубине точки сохранения, допустимой ядром СУБД. |
При успешном выполнении указанный сеанс будет находиться внутри транзакции. Если сеанс ранее был внутри транзакции, будет создана новая точка сохранения.
При сбое транзакционный режим сеанса останется неизменным. Изменение состояния базы данных не произойдет.
Комментарии
Ядро СУБД предоставляет модель изоляции snapshot для своих транзакций. Это означает, что при первом переходе сеанса в состояние транзакции сеанс будет видеть, что вся база данных заморожена во времени в начале транзакции. Сеансу не нужно считывать какие-либо данные блокировки, так как он всегда может получить доступ к соответствующей версии этих данных. Это означает, что сеанс, обновляющий данные, никогда не блокирует чтение этих данных другим сеансом.
Еще одним последствием использования snapshot изоляции является модель блокировки, используемая для обновлений. Ядро СУБД награждет блокировку записи для заданного фрагмента данных первому сеансу, который запрашивает его. Эта блокировка записи освобождается, когда транзакция либо зафиксирована, либо полностью прервана таким образом, что сеанс больше не находится в транзакции. В то время как сеанс удерживает блокировку записи, любой другой сеанс, запрашивающий ту же блокировку записи, не будет блокироваться, пока блокировка записи не станет доступна. Скорее, второй сеанс сразу же завершится сбоем с JET_errWriteConflict. Чтобы устранить этот конфликт, второй сеанс должен полностью прервать (или зафиксировать) свою транзакцию, подождать некоторое время, пока первый сеанс зафиксирует или прервет свою транзакцию, а затем начать все сначала.
Для поддержки изоляции snapshot ядро СУБД сохраняет все версии всех измененных данных в памяти с момента первого запуска самой старой активной транзакции в любом сеансе. Это имеет важные последствия для приложения. Любое поведение, которое приводит к созданию большого количества версий в памяти, может привести к исчерпанию экземпляра максимального размера хранилища версий (дополнительные сведения см. в разделе JET_paramMaxVerPagesв разделе Системные параметры ). Такое поведение включает, помимо прочего, очень большие обновления в одной транзакции и очень длительные транзакции. Поэтому очень важно правильно настроить размер хранилища версий для ожидаемой транзакционной нагрузки приложения. Также важно соблюдать большую осторожность, чтобы ограничить количество обновлений, выполняемых в одной транзакции. Кроме того, в сценариях с высокой нагрузкой важно сделать транзакции как можно более короткими по длительности.
Настоятельно рекомендуется, чтобы приложение всегда было в контексте транзакции при вызове API ESE, которые извлекают или обновляют данные. Если этого не сделать, ядро СУБД автоматически заключает каждый вызов API ESE этого типа в транзакцию от имени приложения. В некоторых случаях стоимость этих очень коротких транзакций может быстро сложиться.
По умолчанию подсистема ограничивает использование сеанса тем же потоком с момента первого вызова JetBeginTransaction до момента выполнения соответствующего вызова JetCommitTransaction или JetRollback . Это поведение можно изменить, чтобы удалить это ограничение, задав пользовательский контекст сеанса с помощью JetSetSessionContext и JetResetSessionContext.
Ядро СУБД также поддерживает изменения схемы транзакций. Например, можно начать новую транзакцию, создать таблицу, добавить несколько столбцов, создать индекс или два, а затем прервать транзакцию. Только что добавленные элементы схемы будут удалены из базы данных. Кроме того, в одной транзакции можно смешивать изменения схемы и обычные обновления базы данных.
Требования
| Требование | Значение |
|---|---|
Клиент |
Требуется Windows Vista, Windows XP или Windows 2000 Профессиональная. |
Сервер |
Требуется Windows Server 2008, Windows Server 2003 или Windows 2000 Server. |
Верхняя часть |
Объявлено в Esent.h. |
Библиотека |
Используйте ESENT.lib. |
DLL |
Требуется ESENT.dll. |
См. также:
JET_ERR
JET_GRBIT
JET_SESID
JetCommitTransaction
JetGetSystemParameter
JetResetSessionContext
JetRollback
JetSetSessionContext
JetStopService
Системные параметры