Способ и система для транзакционных файловых операций по сети

Способ и система для транзакционных файловых операций по сети

Иллюстрации

Показать все

Реферат

Область техники

Различные описанные ниже варианты выполнения относятся, в основном, к сетевым коммуникациям и, в частности, но не исключительно, к способам и системам, позволяющим выполнять транзакционные файловые операции по сети.

Транзакции уже давно обеспечиваются базами данных и системами обработки транзакций. Транзакции обеспечивают упрощенную модель отказов, желательную для прикладных программистов, посредством группирования вместе некоторого количества операций в единственную атомарную операцию, т.е. группу операций, в которой результаты индивидуальных операций остаются действительными или отвергаются вместе. Если происходит сбой только в одной операции, то «отменяется» или выполняется откат действия всех операций в группе, независимо от количества операций, ассоциированных с транзакцией. Это объединение операций предусматривается в отношении любого количества отказов, и, в конце концов, соответствующая система обработки транзакций достигает одного из двух состояний, посредством чего или все операции будут применены, или не будет применена ни одна из операций.

Сущность изобретения

Согласно аспектам различных описанных вариантов выполнения предлагаются способ и система проведения транзакции файловых операций по сети. В одном аспекте вычислительная платформа (т.е. клиент) может дистанционно обращаться к файлу на другой вычислительной платформе (т.е. сервере) по сети. В этом аспекте клиент и сервер включают в себя администратор транзакций (АТ) и файловую систему (ФС). Клиент также включает в себя редиректор (программу переадресации) (РДР), тогда как сервер включает в себя серверный компонент (СРВ).

При работе РДР принимает запрос на удаленную транзакционную файловую операцию. В ответ на запрос РДР производит поиск транзакции в запросе и выполняет маршалинг (трансляцию) транзакции для передачи на сервер (например, посредством АТ в одном варианте выполнения). РДР затем посылает информацию транзакции (например, блоб (большой блок двоичных данных) маршалинга в одном варианте выполнения) на сервер по сети. СРВ принимает информацию транзакции, которую АТ и ФС сервера затем используют для выполнения файловой операции. Сервер затем возвращает результат файловой операции клиенту по сети.

В другом аспекте РДР допускает открытие более одной транзакции удаленной файловой операции для файла. Когда РДР принимает новый запрос на транзакционную удаленную файловую операцию, РДР определяет, известна ли на клиенте «недействительная» версия удаленного файла (т.е. версия, которая была переписана). РДР затем использует недействительную версию нового запроса вместо исходной версии файла. В некоторых вариантах выполнения РДР допускает только единовременное открытие единственной транзакционной операции записи для данного файла.

В еще другом аспекте РДР определяет, может ли новый запрос на транзакционную удаленную файловую операцию использовать информацию о файле, уже известную на клиенте. Если эта же информация о файле может использоваться, то РДР использует эту же информацию о файле, а не запоминает другую копию информации о файле.

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

Краткое описание чертежей

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

Фиг.1 - пример системы, использующей транзакционные удаленные файловые операции;

фиг.2 - пример компонентов клиента и сервера системы по фиг.1;

фиг.3 и 3А - примерная блок-схема последовательности операций обработки для транзакционной удаленной файловой операции между клиентом и сервером по фиг.2;

фиг.4 - пример многочисленных обращений к удаленному файлу клиентом и сервером по фиг.2;

фиг.5 - примерная блок-схема операций обработки для выполнения двухфазной фиксации транзакции по сети;

фиг.6 - пример компонентов для реализации управления транзакциями;

фиг.7 - примерная блок-схема операций обработки для транзакций уровня ядра;

фиг.8 - пример признака защиты; и

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

Подробное описание предпочтительного варианта выполнения

Примерная сетевая среда

Как ранее описано, транзакции использовались в базах данных и системах обработки транзакций, но в нижеследующих вариантах выполнения транзакции используются для удаленных файловых операций. На фиг.1 изображена система 100, в которой клиент может провести транзакцию файловых операций на клиенте по сети 101. В примерной сетевой среде по фиг.1, многочисленные клиентские вычислительные устройства 105, 110, 115 и 120, которые также могут упоминаться как клиентские устройства, подсоединены по меньшей мере к одному серверному устройству 125 по сети 101. Сеть 101, как предполагается, представляет любую из многочисленных обычных сетевых топологий и типов, которые могут включать в себя проводные и/или беспроводные сети. Сеть 101 дополнительно может использовать любой из множества обычных сетевых протоколов, включая общие и/или узкоспециализированные протоколы. Сеть 101 может включать в себя, например, Интернет, а также, возможно, по меньшей мере части одной или нескольких локальных сетей (ЛС), глобальных сетей (ГС) и т.д.

Клиентское устройство 105 может включать в себя любое из множества обычных вычислительных устройств, включая в себя, но не ограничиваясь ими, настольный персональный компьютер (ПК), рабочие станции, мэйнфреймы, устройства для доступа к Интернету и игровые консоли. Другие клиентские устройства, связанные с сетью 101, могут включать в себя персональный цифровой помощник (ПЦП) 110, портативный компьютер 115 и сотовый телефон 120 и т.д., которые могут устанавливать связь с сетью 101 посредством проводной и/или беспроводной линии связи. Дополнительно, один или несколько из клиентских устройств 105, 110, 115 и 120 могут включать в себя некоторые типы устройств или, альтернативно, различные типы устройств.

Серверное устройство 125 может предоставлять любые из множества данных и/или функциональных возможностей вычислительным устройствам 105, 110, 115 и 120. Данные могут быть публично доступными или, альтернативно, ограниченными, например ограниченные только для некоторых пользователей или доступные только, если будет оплачена соответствующая плата и т.д.

Серверное устройство 125 представляет собой по меньшей мере один из сетевого сервера и сервера приложений, или их комбинацию. Серверное устройство 125 представляет собой любое устройство, которое является источником контента (содержания), и клиентские устройства 105, 110, 115 и 120 включают в себя любые устройства, которые принимают такой контент. Поэтому в одноранговой сети устройство, которое является источником контента, упоминается как серверное устройство, и устройство, которое принимает контент, упоминается как клиентское устройство. Оба типа устройств имеют возможность загружать и выполнять программы, включая операционные системы и приложения, согласно примерным вариантам выполнения, описанным в данной заявке. Далее, данные и функциональные возможности могут совместно использоваться клиентскими устройствами 105, 110, 115 и 120. Т.е. сервисное устройство 125 не является единственным источником данных и/или функциональных возможностей для соответствующих клиентских устройств.

На источнике 130 или 135 данных программы, включая операционные системы и приложения, готовятся и/или предоставляются для выполнения любому одному из серверного устройства 125 или клиентских устройств 105, 110, 115 и 120. Для согласованности, описание ниже ссылается на «приложения», которые охватывают любые из, по меньшей мере, программ, операционных систем и приложений, или в единственном числе, или в комбинации, как известно в технике. Кроме того, приложения распределяются на серверное устройство 125 автономно, как например, от источника 130 данных, или неавтономно, как например от источника 135 данных. Далее, приложения обычно распределяются на клиентские устройства 105, 110, 115 и 120 неавтономно от серверного устройства 125 или от источника 135 данных. Также известны средства и способы для их автономного распределения.

Согласно различным вариантам выполнения, описанным ниже, распределение по меньшей мере одного из данных и функциональных возможностей среди устройств 105, 110, 115, 120 и 125 может выполняться в виде транзакции. Более конкретно транзакция представляет собой группу операций, которые выполняются синхронно или асинхронно в виде единственной атомарной (неделимой) операции или в одном из устройств 105, 110, 115, 120 и 125, или в сетевой среде, такой как пример на фиг.1. Пример транзакционных удаленных файловых операций, выполняемых по сети, описывается более подробно ниже в связи с фиг.2-7.

Транзакционная удаленная файловая операция

На фиг.2 изображены компоненты двух устройств системы 100 (например, выбранные из устройств 105, 110, 115, 120 и 125) по фиг.1, которые работают в качестве клиента 202 и сервера 204 для целей транзакционной удаленной файловой операции. В данном варианте выполнения как клиент 202, так и сервер 204 используют версию операционной системы Microsoft® Windows®. В других вариантах выполнения могут использоваться различные операционные системы.

В данном варианте выполнения клиент 202 включает в себя приложение 212, диспетчер 214 ввода-вывода, файловую систему (ФС) 216, селектор 218 редиректора, администратор 222 транзакций (АТ) и редиректор (РДР) 220. Сервер 204 в данном варианте выполнения включает в себя серверный компонент (СРВ) 234, диспетчер 214А ввода-вывода, ФС 216А и АТ 222А. В данном варианте выполнения клиент 202 и сервер 204 могут устанавливать связь друг с другом по сети 100 (фиг.1). В некоторых вариантах выполнения эти компоненты реализуются программно.

В данном варианте выполнения, основанном на Windows, диспетчеры 214 и 214А ввода-вывода, ФС 216 и 216А реализуются файловой системой новой технологии (ФСНТ), и селектор 218 редиректора реализуется при помощи провайдера множественных УСИ (ПМУ), где УСИ представляет собой акроним для универсального соглашения об именовании. Таким образом, селектор 218 редиректора также упоминается в данной заявке как ПМУ 218. Кроме того, РДР и СРВ операционной системы Microsoft® Windows® (с добавленными функциональными возможностями) реализуют РДР 220 и СРВ 234 соответственно. Приведенные для примера дополнения к РДР и СРВ операционной системы Microsoft® Windows® описываются ниже. Далее, в данном варианте выполнения АТ 222 и АТ 222А реализуются в качестве администраторов транзакций уровня ядра в данном варианте выполнения и описываются ниже более подробно. В других вариантах выполнения могут использоваться различные диспетчеры ввода-вывода, файловые системы, селекторы редиректора, АТ и/или РДР.

На фиг.3 изображена приведенная для примера блок-схема последовательности операций обработки для транзакционной удаленной файловой операции между клиентом 202 и сервером 204 (фиг.2). Как показано на фиг.2 и 3, транзакционная удаленная файловая операция выполняется следующим образом согласно одному варианту выполнения.

В блоке 302 РДР 220 принимает запрос на транзакционную файловую операцию на файле, который является резидентным в сервере 204. Типовые файловые операции включают в себя создание нового файла, чтение файла, запись файла, копирование файла, переименование файла и т.д. В данном варианте выполнения запрос на транзакционную файловую операцию генерируется приложением 212, которое представляет собой приложение уровня пользователя, как показано на фиг.2. Запрос использует структуру, которая включает в себя поле для контекста транзакции. Запрос принимается диспетчером 214 ввода-вывода, который определяет, предназначен ли запрос для локального файла или для удаленного файла. В данном варианте выполнения диспетчер 214 ввода-вывода представляет собой стандартный компонент операционной системы Microsoft® Windows®. Например, приложение 212 может выполнить запрос при помощи вызова диспетчера 214 ввода-вывода с именем УСИ (которое присутствует в виде \\сервер\совместно используемый ресурс\подкаталог\имя файла). Диспетчер 214 ввода-вывода затем передает запрос на ПМУ 218. Могут быть многочисленные дескрипторы для транзакции и многочисленные транзакции для данного файла. С другой стороны, если запрос был в отношении файла на клиенте, диспетчер 214 ввода-вывода передает запрос ФСНТ 216 стандартным образом.

ПМУ 218 затем локализует редиректор, необходимый для выполнения запроса. В данном случае редиректором является РДР 220. В данном варианте выполнения ПМУ 218 представляет собой стандартный компонент операционной системы Microsoft® Windows®. В данном варианте выполнения РДР 220 представляет собой версию РДР операционной системы Microsoft® Windows® с дополнением, поэтому РДР может взаимодействовать с АТ 222 для выполнения транзакций. Дополнения включают в себя, например, способность извлекать контексты транзакции для транзакционных файловых операций из запросов, назначать блоки управления файлом (БУФ) для транзакционных файловых операций, посылать транзакции на удаленные устройства по сети, принимать ответы для транзакционных файловых операций (включая идентификаторы файла и идентификаторы версии), выполнять операции транзакции под управлением АТ 222 и вовлекать в качестве администратора ресурсов АТ 222, так что РДР 220 может быть осведомлен в отношении состояния транзакции. В некоторых вариантах выполнения РДР 220 реализуется так, как описано в совместно поданной и переуступленной патентной заявке США №09/539 233, поданной 30 марта 2000 г., на «Транзакционную файловую систему», и заявке №[номер дела поверенного №MS1-1781US]. Вовлечение в качестве администратора ресурсов описывается ниже. РДР 220 содержит ресурсы для буферизации транзакции, отображения кэша, блоков управления файлом (БУФ), расширений файлового объекта (РФО) и других структур, необходимых для обработки транзакции и запроса.

В блоке 304 РДР 220 извлекает транзакцию из АТ 222 и выполняет маршалинг для передачи клиенту 204. В одном варианте выполнения РДР 220 извлекает транзакцию посредством вызова интерфейса прикладного программирования (ИПП) (варианты выполнения которого описаны ниже), раскрываемого при помощи АТ 222, и выполняет маршалинг транзакции посредством форматирования информации транзакции (например, блоба маршалинга) для передачи с использованием версии протокола блока сообщений сервера (БСС), который был расширен для поддержки транзакций. Расширения БСС одного примерного варианта выполнения суммируются ниже в связи с таблицами 1-3. В блоке 306 РДР 220 посылает транзакцию и запрос на сервер 204, как указано стрелкой 236. В блоке 308 РДР 220 принимает результаты файловой операции от сервера 204. Например, сервер 204 посылает ответ на запрос, который содержит вышеупомянутые идентификаторы файла и версии. В данном варианте выполнения СРВ 234 представляет собой версию СРВ операционной системы Microsoft® Windows® с дополнениями, так что СРВ может взаимодействовать с клиентом по сети для выполнения транзакций с использованием расширения для БСС, включая передачу идентификаторов файла и версии клиентам во время транзакционных удаленных файловых операций.

Таблица 1
Расширение	Описание
Добавить новую команду: NT_TRANSACT_CREATE2	Принимает транзакцию с выполненным маршалингом и посылает две структуры по сети: REQ_CREATE_WITH_EXTRA_OPTIONS RESP_CREATE_WITH_EXTRA_OPTIONS.Эти две структуры определены в таблице 2 и 3 соответственно и представляют собой расширения структур БСС: REQ_CREATE_WITH_SD_OR_EA и RESP_EXTENDED_CREATE_WITH_SD_OR_EA
Добавить новый бит возможностей: CAP_TXF	CAP_TXF устанавливается или сбрасывается сервером для указания, поддерживает ли сервер транзакции. CAP_TXF представляет собой часть Negotiate Response БСС. В данном варианте выполнения CAP_TXF определяется как 0х20000 для указания, что сервер поддерживает транзакции.
Добавить новый флаг: SMB_FIND_TRANSACTED_OPERATION на запрос FIND БСС.Структура (REQ_FIND_FIRST2) запроса FIND определяется в таблице 4 и структура ответа - в таблице 5.	SMB_FIND_TRANSACTED_OPERATION указывает, что используется транзакция. Данный флаг используется, потому что в данном варианте выполнения операции поиска являются основанными на пути вместо основанных на дескрипторе. В данном варианте выполнения данный флаг определяется как 0х20. Информация транзакции посылается в конце команд FIND и ECHO, если данный флаг установлен.
Расширяет команду ECHO для посылки уведомлений об изменениях состояния транзакции. Структуры запроса/ответа определяются в таблице 6 и 7.	Команда ECHO БСС расширяется для предоставления уведомления о состояниях предварительной подготовки, подготовки, фиксации, отката операции транзакции с сервера на клиент.

REQ_CREATE_WITH_EXTRA_OPTIONS

Таблица 2
Поле	Описание контента
_ULONG(Flags)	Создание флагов NT_CREATE_xxx
_ULONG(RootDirectoryFid)	Необязательный каталог для относительного открытия
ACCESS_MASK DesiredAccess	Требуемый доступ (формат новой технологии (НТ))
LARGE_INTEGER	Исходный размер выделения в байтах
AllocationSize
_ULONG(FileAttributes)	Атрибуты файла
_ULONG(ShareAccess)	Совместный доступ
_ULONG(CreateDisposition)	Действие для выполнения, существует или нет файл
_ULONG(CreateOptions)	Опции для создания нового файла
_ULONG(SecurityDescriptorLength)	Длина дескриптора защиты (ДБ) в байтах
_ULONG(EaLength)	Длина расширенного атрибута (РА) в байтах
_ULONG(NameLength)	Длина имени в символах
_ULONG(ImpersonationLevel)	Информация о качестве обслуживания (КО) защиты
_UCHAR SecurityFlags	Информация о КО защиты
_ULONG(TransactionLength)	Длина контекста транзакции, выполняемого маршалингом, в байтах
_ULONG(EfsStreamLength)	Длина потока шифрованной файловой системы (ШФС) ($EFS) в байтах
UCHAR Buffer[1]	Буфер для имени файла, который выравнивается в буфере данных до границы DWORD (4 байта)
UCHAR Name[]	Имя файла (не заканчивается NUL)

RESP_CREATE_WITH_EXTRA_OPTIONS

Таблица 3
Поле	Описание контента
UCHAR OplockLevel	Предоставлен уровень уступающей блокировки
UCHAR ExtendedResponse	Устанавливается в 1 для Расширенного ответа
_USHORT(Fid)	Идентификатор файла
_ULONG(CreateAction)	Предпринятое действие
_ULONG(EaErrorOffset)	Смещение ошибки РА
TIME CreationTime	Время создания файла
TIME LastAccessTime	Время обращения к файлу
TIME LastWriteTime	Время последней записи файла
TIME ChangeTime	Время последнего изменения файла
_ULONG(FileAttributes)	Атрибуты файла
LARGE_INTEGER AllocationSize	Количество выделенных байтов
LARGE_INTEGER EndOfFile	Окончание смещения файла
_USHORT(FileType)	Тип файла
_USHORT(DeviceState)	Состояние устройства межпроцессорной связи (МПС) (например, программного канала)
BOOLEAN Directory	TRUE, если данной структурой является каталог
UCHAR VolumeGuid[16]	Глобально уникальный идентификатор (ГУИ) тома
UCHAR FileId[8]	Идентификатор файла
_ULONG(MaximalAccessRights)	Права доступа для владельца сеанса
_ULONG(GuestMaximalAccessRights)	Максимальные права доступа для гостя
LARGE_INTEGER	Идентификатор файла ФСНТ на сервере для различия между различными файлами, имеющими одинаковое имя пути. Одинаковое имя пути может ссылаться на два различных файла, использующих транзакции (TxF).
_ULONG(VersionNum);	Номер версии TxF файла, который открывается

REQ_FIND_FIRST2

Таблица 4
Поле	Описание контента
_USHORT(SearchAttributes)	Поиск атрибутов
_USHORT(SearchCount)	Максимальное количество записей для возврата
_USHORT(Flags)	Дополнительная информация: бит, установленный в0 - закрыть поиск после этого запроса1 - закрыть поиск, если достигнут конец2 - возвратить ключи продолжения
_USHORT(InformationLevel)	Уровень информации
_ULONG(SearchStorageType)	Поиск Типа хранения
UCHAR Buffer[1]	Имя файла

Rsp_find_first2

Таблица 5
Поле	Описание контента
_USHORT(Sid)	Поиск дескриптора
_USHORT(SearchCount)	Количество возвращенных записей
_USHORT(EndOfSearch)	Возвращена ли последняя запись?
_USHORT(EaErrorOffset)	Смещение в списке РА в случае ошибки РА
_ULONG(SearchStorageType)	Поиск типа хранения
_USHORT(LastNameOffset)	Смещение в данных для имени файла последней записи, если серверу он нужен для продолжения поиска; иначе 0

REQ_ECHO

Таблица 6
Поле	Описание контента
UCHAR WordCount	Число слов-параметров=1
_USHORT(SearchCount)	Количество возвращенных записей
_USHORT(EndOfSearch)	Возвращена ли последняя запись?
_USHORT(EaErrorOffset)	Смещение в списке РА в случае ошибки РА
_USHORT(LastNameOffset)	Смещение в данных для имени файла последней записи, если серверу он нужен для продолжения поиска; иначе 0

Rsp_echo

Таблица 7
Поле	Описание контента
UCHAR WordCount	Число слов-параметров=1
_USHORT(SequenceNumber)	Порядковый номер этого эхо
_USHORT(ByteCount)	Число байтов данных; min=4
UCHAR Buffer[1]	Эходанные

На фиг.3А изображен блок 302 (фиг.3) более подробно согласно одному варианту выполнения. В блоке 312 РДР 220 извлекает контекст транзакции для запрашиваемой файловой операции. При открытии транзакционного удаленного файла РДР 220 определяет, ассоциирована ли уже транзакция с запросом. Например, в одном варианте выполнения транзакция ассоциируется с запросом посредством присоединения ее к потоку, но в других вариантах выполнения различные способы могут использоваться для ассоциации транзакции с запросом. В одном варианте выполнения РДР 220 выполняет эту операцию посредством проверки, имеет ли запрос дескриптор транзакции, ассоциированный с ним. Если да, запрос присоединяется к существующей транзакции. Если нет, РДР 220 обрабатывает запрос стандартным образом для нетранзакционных запросов.

РДР 220 затем назначает БУФ запросу. Как упомянуто ранее, многочисленные транзакции с многочисленными запросами могут открывать данный файл. Таким образом, в одном варианте выполнения блока 302 (фиг.3) выполняется блок 314, в котором РДР 220 определяет, может ли существующий БУФ использоваться для запроса. В данном варианте выполнения РДР 220 проверяет, совпадает ли файл (т.е. имя пути) запроса и контекста транзакции, ассоциированного с потоком, выполняющим запрос, с файлом существующего БУФ. Например, если две операции записи одного и того же файла были запрошены в одной и той же транзакции, во время обработки второго запроса БУФ уже существует для первого запроса. Так как обеими операциями являются операции записи, один и тот же БУФ может использоваться для обоих.

Если в блоке 314 РДР 220 определяет, что БУФ существует с таким же контекстом транзакции и таким же файлом (т.е. именем файла) и такой же версией, то тогда в блоке 316 для запроса используется существующий БУФ. В некоторых вариантах выполнения РДР 220 будет использовать БУФ, который имеет самую последнюю версию. Например, если операция чтения файла следует за незафиксированной операцией записи этого же файла, РДР 220 будет использовать версию файла, которая в настоящее время используется операцией записи. Этот подход позволяет более эффективно использовать кэширование.

Однако если в блоке 314 существующий БУФ не может использоваться для запроса, в блоке 318 РДР создает новый БУФ для запроса. В альтернативном варианте выполнения новый БУФ создается для каждого запроса.

На фиг.4 изображен пример многочисленных незафиксированных транзакционных запросов одного и того же файла. Как показано на фиг.4, операция 401 соответствует запросу на операцию чтения файла. Т.е. файловой операцией является «открыть для чтения». Операция 401 имеет дескриптор Н1 и транзакцию Т1, ассоциированные с ней. Версия файла, которая запрашивается при помощи РДР 220 (фиг.2), обозначается как версия А. Предполагая, что это первая незафиксированная транзакция для этого файла, версия А извлекается с сервера 204 (фиг.2) и кэшируется в клиенте 202 (фиг.2).

В более поздний момент времени запрашивается операция 402 на этом же файле. В этом примере операцией 402 также является операция чтения, имеющая дескриптор Н2 и транзакцию Т2. Так как транзакция отлична от транзакции операции 401, РДР 220 снова извлекает версию А файла с сервера 204.

В этом примере затем запрашивается операция 403 над этим же файлом в этой же транзакции, что и операция 402. Таким образом, операция 403 имеет дескриптор Н3 и присоединяется к транзакции Т2. Однако операцией 403 является операция записи в данном примере, и, таким образом, РДР 220 локально запоминает (например, кэширует) версию В файла. Версия В иногда упоминается как «недействительная версия».

Затем запрашивается операция 404 на этом же файле в этой же транзакции, что и операции 402 и 403. Таким образом, операция 404 имеет дескриптор Н4 и также присоединяется к транзакции Т2. В данном примере операцией 404 является операция чтения. В данном варианте выполнения в результате действия блока 314 (фиг.3А) РДР 220 запоминает и, возможно, кэширует версию В для операции 404.

Затем запрашивается операция 405 над этим же файлом в другой транзакции. Таким образом, операция 405 имеет дескриптор Н5 и ассоциируется с новой транзакцией Т3. Так как транзакция отличается от транзакции предыдущих операций, в одном варианте выполнения РДР 220 снова извлекает версию А файла с сервера 204. В другом варианте выполнения РДР 229 распознает, что версия А все еще является текущей версией без обращения за справкой к серверу 204 (фиг.2) и использует «локальную» версию А. Например, данный альтернативный вариант выполнения может использовать оппортунистические блокировки, чтобы получить сведения о любых новых версиях файла, которые являются резидентными в сервере 204. Т.е. РДР 220 может ассоциировать уступающую блокировку с файлом, который не предотвращает запись в файл на сервере 204, но действительно вызывает сигнализацию сервером 204 РДР 220, что блокировка была нарушена. В таком случае РДР 200 будет тогда знать, что версия А больше не является текущей версией. В еще другом варианте выполнения РДР 220 может обратиться за справкой к серверу 204 с целью определения текущей версии файла и затем повторно использовать существующий БУФ, который ассоциируется с текущей версией.

Затем в операции 406 фиксируется транзакция Т2. Это вызывает изменение версии на сервере 204. Эта новая версия, хранимая на сервере 204, обозначается как версия С. Как ранее описано, так как РДР 220 вовлекается в качестве администратора ресурсов во время всех удаленных транзакций, РДР 220 узнает, что сервер 204 имеет новую версию файла.

Затем запрашивается операция 407 на этом же файле в этой же транзакции, что и операция 401. Таким образом, операция 407 имеет дескриптор Н6 и присоединяется к транзакции Т1. Однако так как РДР 220 знает о версии С файла на сервере 204, РДР 220 запоминает и, возможно, кэширует версию С для данной операции. В некоторых вариантах выполнения РДР 220 извлекает версию С с сервера 204.

Аналогично, когда запрашивается операция 408 для этого же файла в этой же транзакции, что и операция 405, операция 408 имеет дескриптор Н7 и присоединяется к транзакции Т3. Снова, так как РДР 220 знает о версии С файла на сервере 204, РДР 220 запоминает и, возможно, кэширует версию С для этой операции.

На фиг.5 показано, как кэшированные данные с клиента 202 (фиг.2) сбрасываются (т.е. долговременно запоминаются) на сервер 204 (фиг.2) согласно одному варианту выполнения. Как показано на фиг.2 и 5, клиент 202 сбрасывает данные на сервер 204, как описано ниже, согласно одному варианту выполнения.

В блоке 502 приложение, генерирующее данные, выполняет вызов или выдает запрос на фиксацию транзакции. Данный вызов или запрос передается на АТ 222. В ответ АТ 222 генерирует Уведомление Pre-prepare (описанное ниже в связи с Примерным администратором транзакций).

В данном варианте выполнения РДР 220 принимает Уведомление Pre-prepare от АТ 222, как показано в блоке 504. В ответ РДР 220 сбрасывает данные на СРВ 234 по сети. СРВ 234 в свою очередь передает данные ФСНТ 216А. Эти операции представляются блоком 506. В некоторых вариантах выполнения АТ 222А сервера 204 сигнализирует РДР 220, когда завершается операция Pre-prepare. Блоки 504 и 506 обеспечивают, что данные с клиента 202, подлежащие записи на сервере 204, присутствуют на сервере 204 до выполнения операции Prepare (описанной ниже в связи с Примерным администратором транзакций).

В блоке 508 РДР 220 принимает Уведомление Prepare (описанное ниже в связи с Примерным администратором транзакций) от АТ 222. В одном варианте выполнения РДР 220 посылает сообщение с Уведомлением Prepare на сервер 204 в ответ на Уведомление Prepare, которое передается на АТ 222А. В свою очередь АТ 222А передает Уведомление Prepare ФСНТ 216А. Эти операции представляются блоками 510 и 512. Уведомление Prepare вызывает запоминание клиентом 202 и сервером 204 данных так, что возможна или фиксация, или откат данных. В некоторых вариантах выполнения АТ 222А сервера 204 сигнализирует РДР 220, когда завершается операция Prepare. Данные затем обрабатываются с использованием стандартных операций двухфазной фиксации (например, операций, которые вызывают фиксацию или преждевременное прекращение транзакции), как представлено блоком 514.

Хотя управление транзакциями описано выше как выполняемое с использованием отдельных компонентов АТ (т.е. АТ 222 и 222А), в других вариантах выполнения инфраструктура управления транзакциями может интегрироваться в инфраструктуру файловой системы. Далее, в таких интегрированных вариантах выполнения сообщения транзакции (например, PrePrepare, Prepare, Commit, Abort и т.д., как описано ниже) передаются с файловыми сообщениями по каналу передачи.

Примерный администратор транзакций

На фиг.6 изображены компоненты, используемые при выполнении транзакции, согласно одному варианту выполнения. Группа операций, которые составляют конкретную транзакцию, должны вместе иметь свойства, известные, по меньшей мере специалисту в данной области техники, под акронимом «АНИД», который включает в себя «атомарность», «непротиворечивость», «изоляцию» и «долговременность». Более конкретно обновления данных, происходящие в результате соответствующих операций транзакции, или все постоянные, или ни одно не является постоянным (атомарность); транзакция оставляет лежащие в основе данные в согласованном состоянии (непротиворечивость); воздействия обновления транзакции не являются видимыми для других одновременно выполняющихся операций до тех пор, пока вся транзакция не сделается постоянной (изоляция); и после определения итога транзакции гарантируется, что результат никогда не будет изменен (долговременность).

Пример управления транзакциями на уровне ядра по фиг.6 касается примера распределенной транзакции, затрагивающей более одного устройства, и поддерживает характеристики «АНИД», ожидаемые от транзакции. Кроме того, хотя пример по фиг.6 ссылается на объекты ядра, пример никоим образом не ограничивается транзакциями, выполняемыми объектами ядра. Более конкретно описанные в данной заявке транзакции могут реализоваться объектами, отличными от объектов ядра, или другим типом администратора транзакций.

На фиг.6 транзакция, соответствующая клиентскому приложению 600, использует, по меньшей мере, администратор 605 транзакций на первом устройстве, а также клиентское приложение 600 В и администратор 635 транзакций на втором устройстве. Клиентское приложение 600 В ассоциируется с клиентским приложением 600. Администраторы 605 и 635 транзакций, которые организуют связь друг с другом, могут быть агрегатами объектов ядра, которые сохраняют информацию о состоянии всех транзакций и ресурсов, и дополнительно координировать взаимодействие или протокол между клиентскими приложениями и ассоциированными администраторами ресурсов (АР).

Администраторы ресурсов, включающие в себя АР 625 и АР 630 в примере на фиг.6, сохраняют состояние по меньшей мере одного лежащего в основе ресурса, который может хранить данные в долговременном состоянии. Неисключающие примеры таких ресурсов включают в себя базы данных и очереди сообщений. В первом устройстве в примерном варианте выполнения по фиг.6 АР 625 соответствует ресурсу 627; АР 630 соответствует ресурсу 632; и во втором устройстве АР 655 соответствует ресурсу 657.

Как показано на фиг.6, администратор 605 транзакций на первом устройстве включает в себя следующие объекты ядра: объект 610 транзакции (ТХ), объект 615 администратора ресурсов (ОАР) и объект 620 вовлечения (ВОВ); и администратор 635 транзакций на втором устройстве включает в себя следующие объекты ядра: ТХ 640, ОАР 645 и ВОВ 650. ТХ представляет конкретную транзакцию и может быть открыт процессом, участвующим в транзакции.

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

ВОВ представляет зависимость между транзакцией и администратором ресурсов. Администратор ресурсов указывает, что он будет участвовать в транзакции посредством создания вовлечения в нее. Когда ОАР запрашивается выполнить операцию (такую как Prepare, Commit и т.д.) в конкретной транзакции, он использует ВОВ для указания участия. Администратор ресурсов может иметь более одного ВОВ на конкретной транзакции.

Протокол двухфазной фиксации, который реализуется для обеспечения, что транзакция успешно обновляет все соответствующие файлы, описывается для среды ядра с ссылкой на примеры по фиг.6 и 7 следующим образом. В частности, после открытия клиентским приложением 600 объектов ядра, соответствующих администратору 605 транзакций на первом устройстве, и открытием СРВ 234 (фиг.2) объектов ядра, соответствующих администратору 635 транзакций на втором устройстве, фаза 705 «подготовки» начинается с того, что каждому АР в транзакции посылается (705) порядок «подготовки» от соответствующего администратора транзакций. Извещенный таким образом АР подготавливается (710) путем представления данных ресурса в долговременном состоянии, так что данные в соответствующих ресурсах могут «фиксироваться» или «отклоняться». После подготовки АР передает 715 сообщение подтверждения на ТХ соответствующего администратора транзакций.

Фаза 720 «фиксации» выполняется при разрешении транзакции, посредством чего ТХ администратора транзакций передает (725) результат транзакции как «фиксировано», или «прекращено/отклонено» на каждый ассоциированный АР. АР затем регистрирует результат в ассоциированном журнале регистрации, и лежащие в основе данные ресурса или фиксируются, или отклоняются в соответствии с итогом транзакции. Альтернативные варианты выполнения могут предусматривать непостоянные вовлечения, для которых данные для транзакции не являются долговременными, и, поэтому, данные ни регистрируются, ни восстанавливаются.

Управление транзакциями на уровне ядра может реализовываться посредством использования интерфейсов прикладного программирования (ИПП), которые применимы к системным архитектурам, включая, но не ограничиваясь ими, интерфейс прикладного программирования Microsoft® Win32® и операци