BRPI0406404B1 - A system for supporting transacted remote file operations between a local device and a remote device, and method for implementing a transacted remote file operation on a local device - Google Patents

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA PARA SUPORTAR OPERAÇÕES DE ARQUIVO REMOTO TRANSACIONADAS ENTRE UM DISPOSITIVO LOCAL E UM DISPOSITIVO REMOTO, E MÉTODO PARA IMPLEMENTAR UMA OPERAÇÃO DE ARQUIVO REMOTO TRANSACIONADA EM UM DISPOSITIVO LOCAL”.

CAMPO TÉCNICO

[001] Várias modalidades descritas abaixo se relacionam geralmente com a comunicação de rede e, mais particularmente porém não exclusivamente com métodos e sistemas para permitir operações de arquivo transacionadas através de uma rede.

FUNDAMENTO DA INVENÇÃO

[002] Há muito tempo as transações tem sido proporcionadas por bases de dados e sistemas de processamento de transação. As transações proporcionam um modelo de falha simplificado, desejável para programadores de aplicação, por agrupar uma série de operações em uma única operação atômica, isto é, um grupo de operações cujos resultados das operações individuais se mantém ou caem juntos. Se somente uma operação falhar, os efeitos de todas as operações no grupo, independente do número de operações associadas com a transação, são "desfeitos" ou revertidos. Esta solidariedade entre as operações é proporcionada com respeito à qualquer número de falhas e eventual mente o sistema de processamento de transação respectivo alcança um de dois estados por meio dos quais todas as operações foram aplicadas ou nenhuma das aplicações foram aplicadas. SUMÁRIO DA INVENÇÃO

[003] De acordo com aspectos das várias modalidades descritas, são proporcionados um método e sistema para transacionar operações de arquivo através de uma rede. Em um aspecto, uma plataforma de computação (isto é, cliente) pode remotamente acessar um arquivo em outra plataforma de computação (isto é, servidor) via a rede. Neste aspecto, cada um dentre o cliente e o servidor inclui um gerenciador de transação (TM) e um sistema de arquivo (FS). O cliente também inclui um redirecionador (RDR), enquanto o servidor inclui um componente de servidor (SRV).

[004] Em operação, o RDR recebe uma requisição para uma operação de arquivo transacionada remota. Em resposta à requisição, o RDR examina procura a transação a partir da requisição e tem a transação conduzida para transmissão para o servidor (por exemplo, o TM em uma modalidade). O RDR então envia a informação de transação (por exemplo, uma bolha de condução em uma modalidade) para o servidor através da rede. O SRV recebe a informação de transação, a qual o TM e o FS do servidor então utilizam para executar a operação de arquivo. O servidor então retorna o resultado da operação de arquivo para o cliente via a rede.

[005] Em outro aspecto, o RDR permite que mais do que uma transação de operação de arquivo remoto seja aberta para um arquivo. Quando o RDR recebe uma nova requisição para uma operação de arquivo remoto transacionada, o RDR determina se uma versão "suja" do arquivo remoto (isto é, uma versão que foi gravada) é conhecida no cliente. O RDR então utiliza a versão suja para a nova requisição ao invés da versão original do arquivo. Em algumas modalidades, o RDR somente permite que uma única operação de gravação transacionada seja aberta ao mesmo tempo para um dado arquivo.

[006] Ainda em outro aspecto, o RDR determina se uma nova requisição para uma operação de arquivo remoto transacionada pode utilizar informações de arquivo já conhecidas no cliente. Se a mesma informação de arquivo puder ser utilizada, o RDR utiliza esta mesma informação de arquivo ao invés de armazenar outra cópia da informação de arquivo.

[007] Ainda em um aspecto adicional, o RDR pode associar um bloqueio oportunistico com transações para um dado arquivo remoto. Em uma modalidade, o bloqueio não impede o servidor local de acessar o arquivo, porém causa que o servidor envie uma mensagem para o cliente de que o bloqueio foi rompido. O RDR pode então verificar se um bloqueio foi rompido para um dado arquivo por determinar se uma nova requisição para um arquivo remoto transacionado pode utilizar informações de arquivo já armazenadas em memória cache no cliente. BREVE DESCRIÇÃO DOS DESENHOS

[008] Modalidades não limitativas e não exaustivas são descritas com referência às seguintes figuras, onde números de referência iguais se referem á partes iguais por todas as várias vistas a menos que seja de outro modo especificado.

[009] A FIG. 1 apresenta um exemplo de um sistema capaz de utilizar as operações de arquivo remoto transacionadas;

[0010] A FIG. 2 apresenta um exemplo de componentes de um cliente de um servidor do sistema da FIG. 1;

[0011] As FIGS. 3 e 3A apresentam fluxos de processamento ilustrativos para uma operação de arquivo remoto transacionada entre o cliente e o servidor da FIG. 2;

[0012] A FIG. 4 apresenta um exemplo de vários acessos ao arquivo remoto pelo cliente e pelo servidor da FIG. 2;

[0013] A FIG. 5 apresenta um fluxo de processamento ilustrativo para executar uma entrega de duas fases de uma transação através de uma rede;

[0014] A FIG. 6 apresenta um exemplo de componentes para implementar o gerenciamento de transação;

[0015] A FIG. 7 apresenta um fluxo de processamento ilustrativo para transações de nível núcleo;

[0016] A FIG. 8 apresenta um exemplo de uma característica de segurança; e [0017] A FIG. 9 apresenta um ambiente de computador geral que pode ser utilizado para implementar técnicas descritas aqui dentro, de acordo com várias modalidades. DESCRICÃO DETALHADA DA MODALIDADE PREFERIDA Ambiente de rede ilustrativo [0018] Como anterior mente descrito, as transações tem sido utilizadas em sistemas de processamento de transação e de base de dados, porém nas seguintes modalidades as transações são utilizadas para operações de arquivo remoto. A FIG. 1 ilustra um sistema 100 no qual um cliente pode transacionar operações de arquivo em um cliente via uma rede 101. No ambiente de rede ilustrativo da FIG. 1, vários dispositivos de computação cliente 105, 110, 115 e 120, os quais também podem ser referidos como dispositivos cliente, estão acoplados com pelo menos um dispositivo servidor 125 via a rede 101. A rede 101 é pretendida para representar qualquer uma dentre uma variedade de topologias e tipos de rede convencionais, os quais podem incluir redes com fios / sem fios. A rede 101 pode adicional mente utilizar qualquer um dentre uma variedade de protocolos de rede convencionais, incluindo protocolos públicos e / ou proprietários. A rede 101 pode incluir, por exemplo, a Internet bem como possivelmente pelo menos partes de uma ou mais redes de área local (LANs), de redes de área ampla (WANs), etc.

[0019] O dispositivo cliente 105 pode incluir qualquer um dentre uma variedade de dispositivos de computação convencionais, incluindo, mas não limitados à um computador pessoal de área de trabalho (PC), estações de trabalho, computadores de grande porte, dispositivos da Internet e consoles de jogo. Os dispositivos cliente adicionais associados com a rede 101 podem incluir o assistente digital pessoal (PDA) 110, computador laptop 115 e o telefone celular 120, etc., os quais podem estar em comunicação com a rede 101 por uma ligação com fios e / ou sem fios. Ainda adicionalmente, um ou mais dentre os dispositivos clientes 105, 110, 115 e 120 podem incluir os mesmos tipos de dispositivos, ou de forma alternativa diferentes tipos de dispositivos.

[0020] O dispositivo servidor 125 pode proporcionar qualquer um dentre uma variedade de dados e / ou de funcionalidade para os dispositivos de computação 105, 110, 115 e 120. Os dados podem ser publicamente disponíveis ou de forma alternativa restritos, por exemplo, restritos à somente certos usuários ou disponíveis somente se uma taxa apropriada for paga, etc.

[0021] O dispositivo servidor 125 é pelo menos um dentre um servidor da rede e um servidor de aplicação, ou uma combinação de ambos. O dispositivo servidor 125 é qualquer dispositivo que seja a fonte de conteúdo e os dispositivos clientes 105, 110, 115 e 120 incluem quaisquer dispositivos que recebem tal conteúdo. Portanto, em uma rede não hierárquica, o dispositivo que é a fonte do conteúdo é referido como o dispositivo servidor e o dispositivo que recebe o conteúdo é referido como o dispositivo cliente. Ambos os tipos de dispositivos estão aptos a carregarem e executarem programas de software, incluindo sistemas operacionais e aplicações, de acordo com as modalidades ilustrativas descritas aqui dentro. Adicionalmente, os dados e a funcionalidade podem ser compartilhados entre os dispositivos clientes 105, 110, 115 e 120. Isto é, o dispositivo de serviço 125 não é a única fonte de dados e / ou de funcionalidade para os respectivos dispositivos clientes.

[0022] Na fonte de dados 130 ou 135, os programas de software, incluindo sistemas operacionais e aplicações, são preparados e / ou proporcionados para qualquer um do dispositivo servidor 125 ou dos dispositivos clientes 105, 110, 115 e 120 para execução. Para o propó- sito de consistência, a discussão aqui dentro posteriormente se refere à "aplicações" que abrangem qualquer um dentre, pelo menos, programas de software, sistemas operacionais e aplicações, tanto de forma singular como em combinação, como conhecido na técnica. Adicionalmente, as aplicações são disseminadas para o dispositivo servidor 125 tanto off-line tal como a partir da fonte de dados 130 como on-line tal como a partir da fonte de dados 135. Ainda adicionalmente, as aplicações são tipicamente disseminadas para os dispositivos clientes 105, 110, 115 e 120 on-line a partir do dispositivo servidor 125 ou da fonte de dados 135. Dispositivos e métodos para disseminação off-line das mesmas também são conhecidos.

[0023] De acordo com várias modalidades descritas abaixo, a disseminação de pelo menos um dentre os dados e a funcionalidade entre os dispositivos 105, 110, 115, 120 e 125 pode ser implementada como uma transação. Mais particularmente, uma transação é um grupo de operações que são executadas de forma síncrona ou de forma assín-crona como uma única operação atômica, tanto dentro dos dispositivos 105, 110, 115, 120 e 125 como em um ambiente de rede, tal como o exemplo da FIG. 1. Um exemplo das operações de arquivo remoto transacionadas executadas através da rede é descrito em maiores detalhes abaixo em conjunto com as FIGs. 2 até 7.

[0024] Operação de arquivo remoto transacionada [0025] A FIG. 2 ilustra componentes de dois dispositivos do sistema 100 (por exemplo, selecionados a partir dos dispositivos 105, 110, 115, 120 e 125) da FIG. 1 que estão operando como um cliente 202 e um servidor 204 para propósitos de uma operação de arquivo remoto transacionada. Nesta modalidade, tanto o cliente 202 como o servidor 204 utilizam uma versão do sistema operacional Microsoft® Windows®. Em outras modalidades, diferentes sistemas operacionais podem ser utilizados.

[0026] Nesta modalidade, o cliente 202 inclui uma aplicação 212, um gerenciador de entrada / saída (E/S) 214, um sistema de arquivos (FS) 216, um seletor redirecionador 218, um gerenciador de transação (TM) 222 e um redirecionador (RDR) 220. O servidor 204, nesta modalidade, inclui um componente servidor (SRV) 234, um gerenciador de E/S 214A, um FS 216A e um TM 222A. Nesta modalidade, o cliente 202 e o servidor 204 podem se comunicar um com o outro via a rede 100 (FIG. 1). Em algumas modalidades, estes componentes são implementados por software.

[0027] Nesta modalidade "Windows", os gerenciadores de E/S 214 e 214A, os FSs 216 e 216A são implementados pelo sistema de arquivos NT (NTFS) e o seletor redirecionador 218 é implementado pelo provedor UNC múltiplo (MUP), onde o UNC é uma acrossemia para Convenção de Nomenclatura Uniforme. Assim, o seletor redirecionador 218 também é referido aqui dentro como MUP 218. Em adição, o RDR e o SRV do sistema operacional Microsoft® Windows® (com funcionalidade adicionada) implementam o RDR 220 e o SVR 234, respectivamente. Adições ilustrativas ao RDR e ao SVR do sistema operacional Microsoft® Windows® são descritas abaixo. Ainda adicionalmente, nesta modalidade, o TM 222 e o TM 222A são implementados como gerenciadores de transação de nível núcleo nesta modalidade ilustrativa e são descritos abaixo em maiores detalhes. Outras modalidades podem utilizar diferentes gerenciadores de E/S, sistemas de arquivos, seletores redirecionadores, TMs e / ou RDRs.

[0028] A FIG. 3 ilustra um fluxo de processamento ilustrativo para uma operação de arquivo remoto transacionada entre o cliente 202 e o servidor 204 (FIG. 2). Referindo-se às FIGs. 2 e 3, uma operação de arquivo remoto transacionada é executada como se segue, de acordo com uma modalidade.

[0029] Em um bloco 302, o RDR 220 recebe uma requisição pela operação de arquivo transacionada em um arquivo residindo no servidor 204. As operações de arquivo típicas incluem criar um novo arquivo, ler um arquivo, gravar um arquivo, copiar um arquivo, renomear um arquivo, etc. Nesta modalidade, a requisição por uma operação de arquivo transacionada é gerada pela aplicação 212, a qual é uma aplicação de nível do usuário como apresentado na FIG. 2. A requisição utiliza uma estrutura que inclui um campo para o contexto de transação. A requisição é recebida pelo gerenciador de E/S 214, o qual determina se a requisição é para um arquivo local ou para um arquivo remoto. Nesta modalidade, o gerenciador de E/S 214 é um componente padrão do sistema operacional Microsoft® Windows®, Por exemplo, a aplicação 212 pode fazer a requisição via uma chamada para o gerenciador de E/S 214 com o nome UNC (o qual está na forma de Wserver\share\subdirectorv\filenameV O gerenciador de E/S 214 então passa a requisição para o MUP 218. Podem existir vários identificadores para uma transação e várias transações para um dado arquivo. Por outro lado, se a requisição fosse para um arquivo no cliente, o gerenciador de E/S 214 passaria a requisição para o NTFS 216 do modo padrão, [0030] O MUP 218 então localiza o redirecionador necessário para executar a requisição. Neste caso, o redirecionador é RDR 220. Nesta modalidade, o MUP 218 é um componente padrão do sistema operacional Microsoft® Windows®. Nesta modalidade, o RDR 220 é uma versão do RDR do sistema operacional Microsoft® Windows®, com adições de modo que o RDR possa interagir com o TM 222 para executar transações. As adições incluem, por exemplo, a capacidade de recuperar contextos de transação para operações de arquivo transacionadas a partir de requisições, designar blocos de controle de arquivo (FCBs) para operações de arquivo transacionadas, enviar transações para dispositivos remotos através da rede, receber respostas para as ope- rações de arquivo transacionadas (incluindo identificadores de Arquivo e identificadores de versão), executar operações de transação sob a direção do TM 222 e funcionar como um gerenciador de recurso com o TM 222 de modo que o RDR 220 possa se manter informado com respeito ao estado de uma transação. Em algumas modalidades, o RDR 220 é implementado como descrito no Pedido de Patente US copen-dente comumente designado Ne 09/539.233, depositado em 30 de Março de 2000, entitulado "Transactional File System" e no Pedido Ne [Processo N- MS1-1781US]. O funcionamento como um gerente de recurso é descrito abaixo. O RDR 220 contém recursos para colocação em memória intermediária da transação, mapa de memória cache, blocos de controle de arquivo (FCBs), extensões de objeto de arquivo (FOBXs) e outras estruturas necessárias para processar a transação e a requisição.

[0031] Em um bloco 304, o RDR 220 recupera a transação a partir do TM 222 e conduz a transação para transmissão para o servidor 204. Em uma modalidade, o RDR 220 recupera a transação por chamar uma API (cujas modalidades são descritas abaixo) exposta pelo TM 222 e conduz a transação por formatar a informação de transação (por exemplo, uma bolha de condução) para transmissão utilizando uma versão do protocolo SMB que foi estendida para suportar transações. As extensões SMB de uma modalidade ilustrativa são resumidas abaixo em conjunto com as Tabelas 1 até 3. Em um bloco 306, o RDR 220 envia a transação e as requisição para o servidor 204, como indicado por uma seta 236. Em um bloco 308, o RDR 220 recebe resultados a partir da operação de arquivo a partir do servidor 204. Por exemplo, o servidor 204 envia uma resposta para a requisição que contém os e identificadores de arquivo e de versão mencionados acima. Nesta modalidade, o SRV 234 é uma versão do SRV do sistema operacional Microsoft® Windows®, com adições de modo que o SRV possa intera- gir com um cliente através de uma rede para executar transações utilizando extensão para SMB, incluindo passar identificadores de Arquivo e de versão para os clientes durante as operações de arquivo remoto transacionadas. EXTENSÃO - DESCRICÃO Adiciona um novo comando: NT_TRANSACT_CREATE2 Pega uma transação conduzida e envia duas estruturas através da rede: REQ_CREATE_WITH_EXTRA_OPTIONS e RESP_CREATE_W ITH_EXTRA_OPTIONS. Estas duas estruturas são definidas, respectívamente, nas Tabelas 2 e 3 e são extensões das estruturas SMB: REQ_CREATE_WITH_SD_OR_EA e RESP_EXTENDED_CREATE_WITH_SD_OR_EA.

Adiciona um novo bit de capacidade: CAP_TXF CAPTXF é estabelecido ou reinidalizado pelo servidor para indicar se o servidor suporta transações. CAP_TXF é parte do SMB Negotiate Response. Nesta modalidade, GAP_TXF é definido como 0x20000 para indicar que o servidor suporta transações.

Adiciona um novo identificador: S M B_F IN D_TR AN S ACTE D_0 P E R ATI O N para a requisição SMB FiND, A estrutura da requisição FIND (REQ_FIND_FIRST2) é definida na Tabela 4 e na estrutura de resposta na Tabela 5, SMB_FlND_TRANSACTED_OPERATION

[0032] Indica que uma transação está sendo utilizada. Este identificador é utilizado porque nesta modalidade, as operações de busca são baseadas em caminho ao invés de baseadas no identificador. Nesta modalidade, este identificador é definido como 0x20. A informação de transação é enviada no fim dos comandos FIND e ECHO se este identificador estiver estabelecido.

[0033] Estende o comando ECHO para enviar notificações de alterações de estado de transação. As estruturas de requisição / resposta são definidas na Tabela 6 e 7.

[0034] O comando SMB ECHO é estendido para proporcionar notificação dos estados de preparo anterior, preparo, entrega e de reversão de uma operação de transação a partir do servidor para o cliente. TABELA 1 REQ_CREATE_WITH_EXTRA_OPTIONS CAMPO - DESCRIÇÃO DO CONTEÚDO _ULONG( Indicadores ) Identificadores de criação NTCREATExxx _ULONG( RootDirectoryFid ) Diretório opcional para abertura relativa ACCESS_MASK DesiredAccess Acesso desejado (formato NT) LARGEJNTEGER AlIocationSize O tamanho de alocação inicial em bytes ULONGÍ FileAttributes ) Os atributos do arquivo _ULONG( Share Access ) O acesso de com parti lhamento _ULONG( CreateDisposition ) Ação a ser tomada se o arquivo existir ou não _ULONG( CreateOptions ) Opções para criar um novo arquivo _ULONG( SecurttyDescriptionLength ) Tamanho do SD em bytes JJLONG ( EaLength ) Tamanho do atributo estendido (EA) em bytes JJLONG ( NameLength ) Tamanho do nome em caracteres _ULONG (ImpersonationLevel) Informação de segurança da Qualidade de Serviço (QOS) JJCHAR SecurityFlags Informações QOS de segurança JJLONG (TransactionLength) Tamanho do contexto da transação conduzida em bytes JJLONG ( EfsStreamLength ) Tamanho do fluxo do sistema de arquivo criptografado ($EFS) em bytes UCHAR Buffer [1] Memória intermediária para o nome do arquivo, a qual é alinhada na memória intermediária de dados com um limite DWORD (4 bytes) UCHAR Name[| O nome do arquivo (não terminado em NUL) TABELA 2 R E S P_C R E ATE_W I TH_EXT R A_0 PT IO N S CAMPO - DESCRIÇÃO DO CONTEÚDO UCHAR OpIocKLevel O nível de bloqueio oportunístico concedido UCHAR - ExtendedResponse Estabelecido para 1 para resposta Estendida _USHORT( Fid ) AID do arquivo _ULONG ( CreateAction ) A ação tomada _ULONG ( EaErrorOffset) Deslocamento do erro EA TIME CreationTime A hora em que o arquivo foi criado TIME LastAcessTime A hora em que o arquivo foi acessado TIME LastWriteTime A hora em que o arquivo foi gravado pela última vez TIME ChangeTime A hora em que o arquivo foi alterado pela última vez _ULONG( FileAttributes )Os atributos do arquivo LARGEJNTEGER AlIocationSize O número de bytes alocados LARGE INTEGER EndOfFile O fim do deslocamento do arquivo JJSHORT ( FileType) O tipo de arquivo do arquivo _USHORT( DeviceState )0 estado do dispositivo IPC (por exemplo, canal) BOOLEAN Directory TRUE se esta estrutura for um diretório UCHAR VolumeGuid [16] A GUID do volume (ID Globalmente Único) UCHAR Fileld[8] O ID do arquivo _ULONG( MaxlmalAccessRights ) Os direitos de acesso para o dono da sessão JJLONG ( GuestMaximalAccessRights) Os direitos de acesso máximos para visitantes LARGEJNTEGER FilesystemFid O Fid NTSF no servidor, para diferenciar entre diferentes arquivos possuindo o mesmo nome de caminho, O mesmo nome de caminho poderia referír-se à dois arquivos diferentes enquanto utilizando transações (TxF) JJLONG (VersionNum );0 número da versão TxF do arquivo que está aberto TABELA 3 REQ_FIND_FIRST2 CAMPO - DESCRICÃO DO CONTEÚDO JJSHORT (SearchAttributes) Atributos de pesquisa _USHORT( SearchCount) Número máximo de registros à se retornar _USHORT( Indicadores ) Informações adicionais: bit estabelecido para 0 - fecha pesquisa após esta requisição; 1 - fecha pesquisa se o fim foi alcançado; 2 - retorna Chaves de reinicio _USHORT( Information Levei) Nível de informação _ULONG(SearchStorageType) Tipo de armazenamento da pesquisa UCHAR Buffer [1] Nome do arquivo TABELA 4 Rsp_find_first2 CAMPO - DESCRICÃO DO CONTEÚDO _USHORT( Sid ) Identificador de pesquisa _USHORT( SearchCount) Número de entradas retornadas _USHORT( EndOfSearch ) A último entrada foi retornada ?

_USHORT( EaErrorOffset) Deslocamento dentro da lista EA se existir erro EA _U L O N G (Sea rchSto rageT y pe) Tipo de armazenamento da pesquisa _USHORT( LastNameOffset) Deslocamento dentro dos dados para o nome de arquivo da última entrada, caso o servidor precise recomeçar a pesquisa; senão 0 TABELA 5 REQECHO CAMPO - DESCRIÇÃO DO CONTEÚDO UCHAR WordCount Contagem de palavras de parâmetro = 1 _USHORT( SearchCount) Número de registros retornados _USHORT( EndOfSearch )A último entrada foi retornada ?

_USHORT( EaErrorOffset) Deslocamento dentro da lista EA se houver erro EA _USHORT( LastNameOffset) Deslocamento dentro dos dados para o nome de arquivo da última entrada, caso o servidor precise do mesmo para recomeçar a pesquisa; senão 0 TABELA 6 Rsp_echo CAMPO - DESCRIÇÃO DQ CONTEÚDO UCHAR WordCount Contagem de palavras de parâmetro = 1 _USHORT( SequenceNumber) Número de sequência deste eco _USHORT( ByteCount) Contagem de bytes de dados; min = 4 UCHAR Buffer[1] Dados ecoados TABELA 7 [0035] A FIG. 3A apresenta o bloco 302 (FIG. 3) em maiores detalhes» de acordo com uma modalidade. Em um bloco 312, o RDR 220 recupera o contexto de transação para a operação de arquivo requisitada. Ao se abrir um arquivo remoto transacionado, o RDR 220 determina se uma transação já está associada com a requisição. Por exemplo, em uma modalidade, uma transação é associada com uma requisição por ligá-la com um encadeamento, porém em outras modalidades diferentes métodos podem ser utilizados para associar uma transação com uma requisição. Em uma modalidade, o RDR 220 executa esta operação por verificar para ver se a requisição possui um identifi- cador de transação associado com a mesma. Caso possua, a requisição é unida com a transação existente. Se não, o RDR 220 manipula a requisição no modo padrão para requisições não transacionadas.

[0036] O RDR 220 então designa um FCB para a requisição. Como anteriormente mencionado, várias transações com várias requisições podem abrir um dado arquivo. Assim, em uma modalidade do bloco 302 (FIG. 3), um bloco 314 é executado no qual o RDR 220 determina se um FCB existente pode ser utilizado para a requisição. Nesta modalidade, o RDR 220 verifica para ver se o arquivo (isto é, nome de caminho) da requisição e do contexto de transação associado com o encadeamento fazendo a requisição se associa com estas de um FCB existente. Por exemplo, se duas operações de gravação do mesmo arquivo fossem requisitadas na mesma transação, durante o processamento da segunda requisição, um FCB já existiría para a primeira requisição. Devido ao fato de ambas as operações serem operações de gravação, o mesmo FCB pode ser utilizado para ambas.

[0037] Se no bloco 314 o RDR 220 determinar que um FCB existe com o mesmo contexto de transação e com o mesmo arquivo (isto é, nome de caminho) e com a mesma versão, então em um bloco 316 o FCB existente é utilizado para a requisição. Em algumas modalidades, o RDR 220 irá utilizar o FCB que possui a versão mais recente. Por exemplo, se uma operação de leitura de um arquivo seguir uma operação de gravação neutra ("uncommitted") do mesmo arquivo, o RDR 220 irá utilizar a versão do arquivo correntemente sendo utilizada pela operação de gravação. Esta maneira de se abordar permite o uso mais eficiente da colocação em memória cache.

[0038] Entretanto, se no bloco 314 um FCB existente não puder ser utilizado para a requisição, em um bloco 318 o RDR cria um novo FCB para a requisição. Em uma modalidade alternativa, um novo FCB é criado para cada requisição.

[0039] A FIG. 4 ilustra um exemplo de várias requisições transacionadas neutras para o mesmo arquivo. Como apresentado na FIG. 4, uma operação 401 corresponde à uma requisição por uma operação de leitura de um arquivo. Isto é, a operação do arquivo é para "abrir para leitura". A operação 401 possui um identificador H1 e uma transação T1 associada com a mesma. A versão do arquivo que é requisitada pelo RDR 220 (FIG. 2) é indicada como versão A. Assumindo-se que esta é a primeira transação neutra para este arquivo, a versão A é recuperada a partir do servidor 204 (FIG. 2) e colocada em memória cache no cliente 202 (FIG. 2) [0040] Em um momento posterior, uma operação 402 é requisitada no mesmo arquivo. Nesta operação ilustrativa 402 também existe uma operação de leitura, possuindo um identificador H2 e uma transação T2. Devido ao fato da transação ser diferente desta da operação 401, o RDR 220 novamente recupera a versão A do arquivo a partir do servidor 204.

[0041] Neste exemplo, uma operação 403 é então requisitada no mesmo arquivo na mesma transação da operação 402. Assim, a operação 403 possui um identificador H3 e é unido com a transação T2. Entretanto, a operação 403 é uma operação de gravação neste exemplo e assim, o RDR 220 localmente se lembra (por exemplo, coloca em memória cache) de uma versão B do arquivo. A versão B é algumas vezes referida como uma "versão suja".

[0042] Uma operação 404 é então requisitada no mesmo arquivo na mesma transação das operações 402 e 403. Assim, a operação 404 possui um identificador H4 e também é unida com a transação T2. Neste exemplo, a operação 404 é uma operação de leitura. Nesta modalidade, resultando a partir do bloco 314 (FIG. 3A), o RDR 220 irá se lembrar e possivelmente colocar em memória cache a versão B para a operação 404.

[0043] Uma operação 405 é então requisitada no mesmo arquivo em uma transação diferente. Assim, a operação 405 possui um identificador H5 e está associada com uma nova transação T3. Devido ao fato da transação ser diferente desta das operações anteriores, em uma modalidade o RDR 220 novamente recupera a versão A do arquivo a partir do servidor 204. Em outra modalidade, o RDR 220 reconhece que a versão A ainda é a versão corrente sem consultar o servidor 204 (FIG. 2) e utiliza a versão "local" A. Por exemplo, esta modalidade alternativa pode utilizar bloqueios oportunísticos para se tornar ciente de quaisquer versões mais novas do arquivo que reside no servidor 204. Isto é, o RDR 220 pode associar um bloqueio oportunístico com o arquivo que não impede gravações junto ao arquivo no servidor 204, mas causa que o servidor 204 sinalize para o RDR 220 que o bloqueio foi rompido. Em tal caso, o RDR 200 então saberia que a versão A não é mais a versão corrente. Ainda em outra modalidade, o RDR 220 pode consultar o servidor 204 para determinar a versão corrente do arquivo e então reutilizar um FCB existente que está associado com a versão corrente.

[0044] Então, em uma operação 406, a transação T2 é entregue ("committed"). Isto possui o efeito de alterar a versão no servidor 204. Esta nova versão armazenada no servidor 204 é referida como versão C. Como foi anteriormente descrito, devido ao fato do RDR 220 funcionar como um gerenciador de recurso durante todas as transações remotas, o RDR 220 aprende que o servidor 204 possui uma nova versão do arquivo.

[0045] Uma operação 407 é então requisitada no mesmo arquivo na mesma transação da operação 401. Assim, a operação 407 possui um identificador H6 e é unida com a transação T1. Entretanto, devido ao fato do RDR 220 estar ciente da versão C do arquivo no servidor 204, o RDR 220 se lembra e possivelmente coloca em memória cache a versão C para esta operação. Em algumas modalidades, o RDR 220 recupera a versão C a partir do servidor 204.

[0046] De forma similar, quando uma operação 408 é requisitada para o mesmo arquivo pela mesma transação da operação 405, a operação 408 possui um identificador H7 e é unida com a transação T3. Novamente, devido ao fato do RDR 220 estar ciente da versão C do arquivo no servidor 204, o RDR 220 se lembra e possivelmente coloca em memória cache a versão C para esta operação.

[0047] A FIG. 5 ilustra como os dados colocados em memória cache a partir do cliente 202 (FIG. 2) são atualizados para (isto é, de forma durável armazenados no) servidor 204 (FIG. 2), de acordo com uma modalidade. Referindo-se às FIGS. 2 e 5, o cliente 202 atualiza dados para o servidor 204 como descrito abaixo, de acordo com uma modalidade.

[0048] Em um bloco 502, a aplicação gerando os dados faz uma chamada ou emite uma requisição para entregar a transação. Esta chamada ou requisição é passada para o TM 222. Em resposta, o TM 222 gera uma Notificação de Preparo anterior (descrita abaixo em conjunto com o Gerenciador de Transação ilustrativo).

[0049] Nesta modalidade, o RDR 220 recebe a Notificação de Preparo Anterior a partir do TM 222, como apresentado em um bloco 504. Em resposta, o RDR 220 atualiza os dados para o SRV 234 via a rede. O SRV 234 por sua vez passa os dados para o NTFS 216A. Estas operações são representadas por um bloco 506. Em algumas modalidades, o TM 222A do servidor 204 indica ao RDR 220 quando a operação de Preparo Anterior estiver completa. O bloco 504 e 506 ajuda a garantir que os dados a partir do cliente 202 a serem gravados no servidor 204 estejam presentes no servidor 204 antes de uma operação de Preparo (descrita abaixo em conjunto com o Gerenciador de Transação Ilustrativo) ser executada.

[0050] Em um bloco 508, o RDR 220 recebe um Notificação de Preparo (descrita abaixo em conjunto com o Gerenciador de Transação Ilustrativo) a partir do TM 222. Em uma modalidade, o RDR 220 envia uma mensagem Notificação de Preparo para o servidor 204 em resposta à Notificação de Preparo, a qual é passada para o TM 222A. Por sua vez, o TM 222A passa a Notificação de Preparo para o NTFS 216A. Estas operações são representadas pelos blocos 510 e 512. A Notificação de Preparo causa que o cliente 202 e o servidor 204 armazenem os dados de um modo que permita aos dados serem entregues ou revertidos. Em algumas modalidades, o TM 222A do servidor 204 indica ao RDR 220 quando a operação de Preparo estiver completa. Os dados são então processados utilizando operações de entrega de duas fases padrão (por exemplo, operações que causam que a transação seja entregue ou cancelada), como representado por um bloco 514.

[0051] Apesar do gerenciamento de transação ser descrito acima como sendo executado utilizando componentes TM separados (isto é, TM 222 e 222A), em outras modalidades a infra-estrutura de gerenciamento de transação pode ser integrada na infra-estrutura do sistema de arquivos. Adicionalmente, em tais modalidades integradas, as mensagens de transação (por exemplo, Preparo Anterior, Prepara, Entrega, Cancela, etc., como descrito abaixo) fluem com as mensagens de arquivo no canal de transmissão. gerenciador de transação ilustrativo [0052] A FIG. 6 ilustra componentes utilizados na execução de uma transação, de acordo com uma modalidade. Um grupo de operações que constituem uma transação particular são para de forma coletiva possuírem propriedades conhecidas, pelo menos para estas na técnica, pela acrossemia "ACID", a qual inclui "atomicidade", "consistência", "isolamento" e "durabilidade". De forma mais específica: todas as atualizações de dados resultando a partir das respectivas operações de uma transação são permanentes ou nenhuma é permanente (atomicidade); uma transação deixa os dados subjacentes em um estado consistente (consistência); os efeitos de uma atualização de transação não são visíveis às outras operações executando simultaneamente até a transação geral ser feita permanente (isolamento); e após um resultado para a transação ter sido determinado, o resultado é garantido de nunca se alterar (durabilidade).

[0053] O exemplo de gerenciamento de transação de nível núcleo da FIG. 6 é direcionado para um exemplo de uma transação distribuída, envolvendo mais do que um dispositivo e mantém as características "ACID" esperadas de uma transação. Adicionalmente, ao passo que o exemplo da FIG. 6 referencia objetos núcleo, o exemplo não está de modo algum limitado às transações implementadas pelos objetos núcleo. De forma mais específica, as transações, descritas aqui dentro, podem ser implementadas por objetos diferentes dos objetos núcleo, ou por um tipo diferente de gerenciador de transação.

[0054] Na FIG. 6, uma transação correspondendo à aplicação cliente 600 utiliza, pelo menos, o gerenciador de transação 605 em um primeiro dispositivo, bem como a aplicação cliente 600B e o gerenciador de transação 635 em um segundo dispositivo. A aplicação cliente 600B está associada com a aplicação cliente 600. Os gerenciadores de transação 605 e 635, os quais estão em comunicação um com o outro, podem ser agregados de objetos núcleo que mantém informação de estado sobre as transações e recursos gerais e adicionalmente coordenam a interação ou o protocolo entre aplicações cliente e gerenciadores de recurso (RM) associados.

[0055] Os gerenciadores de recurso, incluindo o RM 625 e o RM 630 no exemplo da FIG. 6, mantém o estado de pelo menos um recurso subjacente que é capaz de armazenar dados em um estado durável.

Exemplos não exclusivos de tais recursos incluem bases de dados e filas de mensagem. Em um primeiro dispositivo na modalidade ilustrativa da FIG. 6, o RM 625 corresponde ao recurso 627; O RM 630 corresponde ao recurso 632; e em um segundo dispositivo, o RM 655 corresponde ao recurso 657.

[0056] Como apresentado na FIG. 6, o gerenciador de transação 605 em um primeiro dispositivo inclui os seguintes objetos núcleo: objeto de transação (TX) 610, o objeto gerenciador de recurso (RMO) 615 e o objeto de alistamento (EN) 620; e o gerenciador de transação 635 em um segundo dispositivo inclui os seguintes objetos núcleo: TX 640, RMO 645 e EN 650. O TX representa uma transação particular e pode ser aberto por um processo participando na transação.

[0057] O RMO representa um recurso que participa em uma transação particular. A participação pelo RMO em uma transação inclui receber mensagens de entrega de duas fases. Adicionalmente, o RMO é persistente de modo que o gerenciador de transação correspondente sabe qual resultado de transação é para ser transmitido para um RM correspondente. De forma alternativa, o RMO pode ser transitório assim permitindo às aplicações cliente aderirem à um fluxo de notificações de transação sem gerenciar um RMO persistente através das falhas.

[0058] O EN representa a relação entre uma transação e um gerenciador de recurso. Um gerenciador de recurso indica que ele irá participar em uma transação por criar um alistamento no mesmo. Quando o RMO foi requisitado para executar uma operação (tal como Prepara, Entrega, etc.) em uma transação particular, ele utiliza o EN para indicar a participação. Um gerenciador de recurso pode possuir mais do que um EN em uma Transação particular.

[0059] O protocolo de entrega de duas fases, o qual é implementado para garantir que uma transação de forma bem sucedida atualize todos os arquivos apropriados, é descrito para um ambiente núcleo com referência aos exemplos das FIGS. 6 e 7, como se segue. Em particular, após a aplicação cliente 600 abrir os objetos núcleo correspondendo ao gerenciador de transação 605 em um primeiro dispositivo e o SRV 234 (FIG. 2) abrir objetos núcleo correspondendo ao gerenciador de transação 635 em um segundo dispositivo, uma fase de "preparo" 705 começa com sendo enviado 705 para cada RM na transação uma ordem "prepara" a partir de um gerenciador de transação correspondente. Assim alertado, o RM se prepara 710 por sintetizar dados de recurso em um estado durável de modo que os dados nos respectivos recursos sejam capazes de serem "entregues" ou "revertidos". Quando da preparação, o RM transmite 715 uma mensagem de confirmação para o TX do gerenciador de transação correspondente.

[0060] A fase de "entrega" 720 é executada quando de uma resolução da transação, por meio da qual o TX do gerenciador de transação transmite 725 um resultado de transação de "entregue" ou de "cancela / revertido" para cada RM associado. O RM então grava o resultado em um registro de eventos associado e os dados de recurso subjacentes são entregues ou revertidos, de acordo com o resultado da transação. As modalidades alternativas podem permitir que alistamentos voláteis para os quais os dados para a transação não são duráveis e portanto os dados não são registrados ou recuperados.

[0061] O gerenciamento de transação no nível núcleo pode ser implementado por utilizar interfaces de programa de aplicação (API) que são aplicáveis às arquiteturas de sistema incluindo, mas não limitadas à interface de programação de aplicação do Microsoft® Win32® e ao sistema operacional Microsoft® Windows®. As APIs descritas aqui dentro são expostas via uma interface baseada em identificador, um "identificador" referenciando o objeto pretendido pela API. Adicionalmente, a menos que a operação assíncrona seja explicitamente requi- sitada, as operações nos objetos núcleo respectivos, particularmente no TX e no RMO, são síncronas. Ainda adicionalmente, as operações correspondendo à diferentes modalidades de uma transação podem ser implementadas por várias combinações de uma ou mais das APIs descritas aqui dentro. Isto é, algumas modalidades podem utilizar todas as APIs descritas aqui dentro, enquanto outras modalidades podem utilizar várias combinações das mesmas.

[0062] As APIs para implementar operações em objetos núcleo TX e uma descrição correspondente da funcionalidade da API são proporcionadas abaixo (descrições mais detalhadas das rotinas associadas também são proporcionadas adicionalmente abaixo): PreprepareEnlistment: também conhecido como processamento de "Fase 0", requisita que o TX transmita uma mensagem de preparo anterior para todos os RMs associados; • PrepareEnlistment: requisita que o TX transmita uma requisição de preparo para todos os RMs incluídos. • CreateTransaction: abre um novo TX; • OpenTransaction: abre um TX existente; • CommitTransaction: requisita que o TX seja entregue; • RolIbackTransaction: requisita que o TX cancele ou reverta a transação; • SavePointTransaction: requisita que o TX salve o estado da transação; • GetTransactionlnfo: recupera informação sobre o TX; e • SetTransactionlnfo: estabelece informação sobre o TX.

[0063] As APIs utilizadas para implementar operações em objetos núcleo RMO e uma descrição correspondente da funcionalidade da API são proporcionadas abaixo (as descrições mais detalhadas das rotinas associadas também são proporcionadas adicionalmente abaixo): CreateResourceManager: cria um novo RMO que represen- ta um recurso;

OpenResourceManager: abre um RMO existente; DestroyResourceManager: destrói o RMO, assim sinteti-zando-o de forma não persistente;

GetResourceManagerlnfo: recupera informação sobre o RMO;

SetResourceManagerlnfo: estabelece informação sobre o RMO;

CreateEnlistment: causa que o RMO junte-se à uma transação e recupere notificações relacionadas; e GetNotificationResourceManager: consulta e retorna uma notificação RM disponível.

[0064] As APIs utilizadas para implementar operações em objetos núcleo TX por um objeto núcleo RMO após juntar-se à uma transação e uma descrição correspondente da funcionalidade da API são proporcionadas abaixo (descrições mais detalhadas das rotinas associadas também são proporcionadas adicionalmente abaixo): • PrePrepareComplete: indica que o RM completou a preparação anterior como requisitado por um gerenciador de transação correspondente; • PrepareComplete: indica que o RM completou a preparação de uma transação como requisitado pelo gerenciador de transação correspondente; • RolIbackComplete: indica que o RM completou a reversão do trabalho de transação executado como requisitado pelo gerenciador de transação correspondente; e • CommitComplete: indica que o RM completou a entrega do trabalho de transação como requisitado pelo gerenciador de transação correspondente.

[0065] Infelizmente, as APIs associadas com objetos núcleo TX, RMO e ΕΝ utilizadas para implementar o gerenciamento de transação podem expor um ou mais dos objetos núcleo à vários ataques de segurança. Por exemplo, um RM malicioso ou inválido podería se incluir em uma transação para causar ataques de negação de serviço por nunca responder à chamadas de função ou, alternativamente, por forçar cancelamentos de transação. Portanto, um exemplo ilustrativo adicional, também referindo-se à FIG. 6, é direcionado para uma transação distribuída segura, de nível núcleo.

[0066] A modalidade ilustrativas da FIG. 6 adicionalmente proporciona uma solução de segurança para objetos núcleo vulneráveis por aplicar um descritor de segurança, o qual pode incluir uma lista de controle de acesso (ACL), para pelo menos um dos respectivos objetos núcleo.

[0067] Em um primeiro dispositivo, a ACL 660 é aplicado junto ao TX 610, a ACL 665 é aplicado junto ao RMO 615 e a ACL 670 é aplicado junto ao EN 620. Em um segundo dispositivo, a ACL 675 é aplicado ao TX 640, a ACL 680 é aplicado ao RMO 645 e a ACL 685 é aplicado junto ao EN 650.

[0068] Uma ACL define os "direitos" que um usuário particular ou grupo de usuários é permitido ou negado de exercer em um objeto particular. De forma mais específica, como apresentado no ACL 810 ilustrativo da FIG. 8, um ACL que é aplicado ou ligado com um objeto núcleo inclui pelo menos a entrada de controle de acesso (ACE) que compreende um identificador de segurança correspondente (SID) e um conjunto correspondente de direitos. As entradas ACE 1 à 12 na FIG. 8 incluem, respectivamente, os SIDs correspondentes 1 até 12 e os RIGHTs correspondentes 1 até 12.

[0069] Os SIDs 1 até 12 identificam um usuário ou um grupo de usuário que podem tentar implementar uma operação, ou uma série de operações, no objeto núcleo junto ao qual a ACL está aplicado. Os RIGHTs 1 até 12 especificam uma operação ou séries de operações capazes de serem executadas no objeto núcleo respectivo pelo usuário ou grupo de usuários identificado pelo SID e adicionalmente especificam a acessibilidade de tal operação ou operações para o usuário ou grupo de usuários identificado. Isto é, os RIGHTs 1 até 12 podem indicar que o usuário ou o grupo de usuários identificado é permitido de executar uma operação especificada ou que o usuário ou grupo de usuários identificado está proibido de executar uma operação especificada.

[0070] O que se segue é uma lista de operações ilustrativas que podem ser especificadas pelos RIGHTs 1 até 12 em uma ACL aplicada junto ao TX, seguida por uma descrição da funcionalidade da operação. Os RIGHTs 1 até 12 adicionalmente especificam que a operação é permitida ou negada no TX para o usuário ou grupo de usuários identificado pelo SID correspondente. • TRANSACTION_QUERY_INFORMATION: para obter informações sobre o TX; • TRANSACTION_SET_INFORMATION: para estabelecer informações sobre o TX; • TRANSACTION_ENLIST: para incluir no TX na transação; • TRANSACTION_COMMIT: para sintetizar todas as atualizações de dados associadas com o TX duráveis; • TRANSACTION_ROLLBACK: para cancelar, isto é, reverter a operação no TX; • TRANSACTION PROPOGATE: para transmitir dados a partir do TX para outro objeto; • TRANSACTION SAVEPOINT: para salvar o ponto corrente da transação; e • TRANSACTION MARSHAL: para transmitir dados com respeito à transação para outro dispositivo.

[0071] O que se segue é uma lista de operações ilustrativas que podem ser especificadas pelos RIGHTs 1 até 12 em uma ACL aplicada junto ao RMO, seguido por uma descrição da funcionalidade da operação. Os RIGHTs 1 até 2 adicionalmente especificam que a operação é permitida ou negada no RMO para o usuário ou grupo de usuários identificado pelo SID correspondente. • RESOURCEMANAGER_QUERY_INFORMATION: para obter informações sobre o RMO; • RESOURCEMANAGER_SET_INFORMATION: para estabelecer informações sobre o RMO; • RESOURCEMANAGER_RECOVER: para determinar o estado de uma transação no momento da falha da transação; • RESOURCEMANAGER_ENLIST: para incluir o RMO em uma transação; • RESOURCEMANAGER_GET_NOTIFICATION: para receber notificação quando da resolução da transação a partir do gerenciador de transação; • RESOURCEMANAGER_REGISTER_PROTOCOL: para registrar um protocolo que o RMO suporta na transação; e • RESOURCEMANAGER_COMPLETE_PROPOGATION: para estabelecer o recurso de acordo com a resolução da transação;

[0072] O que se segue é uma lista de operações ilustrativas que podem ser especificadas pelos RIGHTs 1 até 12 em uma ACL aplicada junto ao EN, seguida por uma descrição da funcionalidade da operação. Os RIGHTs 1 até 12 adicionalmente especificam que a operação é permitida ou negada no EN para o usuário ou grupo de usuários identificado pelo SID correspondente. • ENLISTMENT_QUERY_INFORMATION: para obter informações sobre o EN; • ENLISTMENT_SET_INFORMATION: para estabelecer in- formações sobre o EN; • ENLISTMENT_RECOVER: para determinar o estado da inclusão no momento da falha da transação. • ENLISTMENT_REFERENCE: para obter e referenciar (ou retirar referência de) uma chave de inclusão; • ENLISTMENT_SUBORDINATE_RIGHTS: para reverter a transação e para responder à notificações; e • ENLISTMENT_SUPERIOR_RIGHTS: para executar operações que um gerenciador de transação superior executaria; tal como iniciar uma operação de preparo anterior, preparo ou de reversão superior em uma transação.

[0073] Por conseqüência, cada um dos objetos núcleo TX, RMO e EN pode possuir uma ACL respectivamente aplicado ao mesmo. Assim, quando uma API tenta iniciar uma operação em um respectivo dos objetos núcleo, a ACL deve ser respeitada por determinar se a operação é permitida ou negada para o usuário ou grupo de usuários a partir do qual a API se origina.

[0074] De forma mais específica, quando um identificador é aberto para executar uma operação, um usuário ou grupo de usuários correspondendo à API é verificado junto com o SID na ACL; uma lista de operações permitidas é gerada; e a operação especificada pela API é verificada para as operações permitidas para o SID em um dado identificador.

[0075] As modalidades alternativas para garantir o gerenciamento de transação entre os objetos núcleo e reforçar os parâmetros de segurança, incluem aplicar descritores de segurança para objetos núcleo que podem participar em uma transação de acordo com o modelo de segurança para o sistema operacional Microsoft® Windows®.

[0076] Como relatado acima, as APIs são expostas como uma interface baseada em identificador, a qual é utilizada para implementar o modelo de segurança. O que se segue inclui uma descrição mais detalhada das APIs, listadas acima, para implementar operações nos objetos núcleo TX. As descrições incluem uma descrição da rotina, dos argumentos correspondentes e dos valores de retorno PreprepareEnlistment (INPHANDLETransactionHandle; INPHANDLEResourceManagerHandle).

[0077] Esta rotina requisita que uma Transação seja "preparada anteriormente" por emitir uma requisição de Preparo Anterior para todos os RMs associados. O Preparo Anterior permite à um RM com propriedades de armazenamento em memória cache uma oportunidade para atualizar suas memórias intermediárias, possivelmente para outros RMs, antes da Transação entrar no estado Preparado, no qual os RMs à jusante não podem mais aceitar alterações.

[0078] Se esta rotina não for chamada e uma transação participante requisitou o processamento PhaseO, as requisições de Preparo Anterior são emitidas à medida que requisitadas quando um Preparo é recebido. Entretanto, algumas configurações que incluem RMs do tipo de memória cache podem causar reversões de transação desnecessárias em cenários distribuídos se não existir nenhum PreprepareEnlistment.

Argumentos: TransactionHandle: Fornece um identificador indicando a Transação a ser preparada anteriormente;

ResourceManagerHandle: Fornece um identificador para o Superior/TM-CRM que está preparando anteriormente a transação. Somente este Superior-TM/CRM estará apto a chamar PrepareEnlis-tment, SuperiorCommitTransaction e SuperiorRollbackTransaction nesta transação.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUSJNSUFFICIENTRESOURCES

ST ATUS_TM_T 00_LATE

PrepareEnlistment (INPHANDLETransactionHandle, INPHANDLEResourceManagerHandle);

[0079] Esta rotina requisita que uma Transação seja "preparada" por emitir uma requisição de Preparo para todos os seus ResourceMa-nagers associados. Esta requisição começa com o protocolo de entrega de duas fases.

[0080] Um participante da transação emitindo o PrepareEnlistment sintetiza o objeto da transação em um estado durável que irá sobreviver às falhas do sistema ou da aplicação; tal participante executa a recuperação na transação após qualquer tipo de falha de modo a distribuir um resultado. A falha para preencher este requerimento pode resultar em perdas de recurso, bem como em resultados de transação inconsistentes.

Argumentos: TransactionHandle: Fornece um identificador para a Transação ser preparada; e ResourceManagerHandle: Fornece um identificador para um TM que está preparando a transação. Se a transação foi preparada anteriormente (via uma chamada ao PreprepareEnlistment), então o ResourceManagerHandle se associa com o Superior-TM/CRM que foi utilizado na chamada ao PreprepareEnlistment. Adicionalmente, somente o Superior-TM/CRM que chama esta API será permitido de chamar SuperiorCommitTransaction e SuperiorRollbackTransaction nesta transação.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_T 00_LATE

STATUS_RM_NOT_RECOVERABLE

CreateT ransaction (OUT PHANDLETransactionHandle, IN ULONGDesiredAccess OPTIONAL; IN POBJECT_ATTRIBUTESObjectAttributes OPTIONAL; IN ULONGCreateOptions OPTIONAL; IN PHANDLEResourceManagerHandle OPTIONAL; IN NOTIFICATION_MASKNotificationMask OPTIONAL; IN LPVOlDTransactionKey OPTIONAL).

[0081] Esta rotina cria um novo objeto Transaction e retorna um identificador para o novo objeto.

[0082] De forma alternativa (caso o parâmetro ResourceManage-rHandle seja especificado), esta rotina executa uma operação "Join" no Transaction após ele ser de forma bem sucedida criado.

[0083] Os clientes fecham o identificador de transação utilizando a API CloseHandle. Se o último identificador da transação se fechar sem ninguém chamando CommitTransaction na transação, então a transação é implicitamente revertida.

Argumentos: TransactionHandle: Fornece um ponteiro para a localização que irá receber um identificador para a nova Transaction;

DesiredAccess: Fornece a máscara especificando o nível de acesso desejado.

As escolhas de máscara de acesso válidas são: SYNCHRONIZEPode executar operações de sincronização neste identificador TRANSACTION COMMITPode utilizar este identificador para entregar a transação TRANSACTION PREPAREPode utilizar este identificador para entregar a transação TRANSACTION ROLLBACKPode utilizar este identificador para cancelar a transação TRANSACTION SAVEPOINTPode utilizar este identificador para criar pontos de salvamento para a transação TRANSACTION JOINPode utilizar este identificador para unir esta transação como um RM TRANSACTIONREADATTRIBUTESPode ler atributos associados com a transação TRANSACTION WRITE ATTRIBUTESPode escrever atributos associados com a transação;

ObjectAttributes: Fornece um ponteiro para uma estrutura de atributos de objeto opcional;

CreateOptionFornece indicadores de transação opcionais. Escolhas de indicador create válidas incluem: TRANSACTIONCREATEPRESUMEDNOTHINGCria uma transação "nada presumido".

ResourceManagerHandle: Fornece um identificador para o ResourceManager que recebe notificações a cerca de uma transação especificada;

NotificationMask: Especifica as notificações que este Re-sourceManager gostaria de receber com respeito à este Transaction; e TransactionKey: Especifica um valor de ponteiro opaco que o RM gostaria de receber junto com quaisquer modificações para este Transaction. O RM pode utilizar isto para associar notificações com algum objeto no espaço de endereço do RM, assim prevenindo a necessidade de executar uma busca cada vez que uma notificação ocorrer.

Valor de Retorno: STATUSSUCCESS

STATUSJ N VALI D_PARAM ETER

STATUS_OBJECT_NAME_COLLISION

STATU S_0 B J ECT_N AM E_l N VALI D

STATUS_PRIVILEGE_NOT_HELD

STATUS_INSUFFICIENT_RESOURCES

OpenTransaction (OUT PHANDLETransactionHandle, INACCESS_MASKDesiredAccess, INPOBJECT_ATTRIBUTESObjectAttributes, INPHANDLEResourceManagerHandle optional, INNOTIFICATIONMASKNotificationMask optional, INLPVOlDTransactionKey optional);

[0084] Esta rotina procura por um objeto Transaction existente e retorna um identificador para o Transaction. O chamador especifica uma representação de cadeia de caracteres de uma GUID em um campo ObjectName de ObjectAttributes.

[0085] De forma alternativa (caso o parâmetro ResourceManage-rHandle seja especificado), esta rotina também executa uma operação "Join" no Transaction após ele ser aberto.

[0086] Os clientes fecham o identificador da transação utilizando uma API CloseHandle. Se o último identificador da transação fechar sem ninguém chamando CommitTransaction na transação, então a transação é implicitamente revertida.

Argumentos: TransactionHandle: fornece um ponteiro para a localização que irá receber um identificador para a Transaction se a operação de abertura for bem sucedida;

DesiredAccess: Fornece a máscara especificando o nível desejado de acesso;

ObjectAttributes: Fornece um ponteiro para uma estrutura de atributos de objeto opcional;

ResourceManagerHandle: Fornece um identificador para o Resource-Manager que recebe notificações a cerca do Transaction especificado; NotificationMask: Especifica as notificações que este ResourceMana-ger pode receber com respeito à este Transaction; e TransactionKey: Opcionalmente especifica um valor de ponteiro opaco que o RM gostaria de receber junto com quaisquer modificações para este Transaction. O RM pode utilizar isto para associar notificações com algum objeto no espaço de endereço do RM, assim prevenindo a necessidade de executar uma busca cada vez que uma notificação ocorrer.

Valor de Retorno: STATUS_SUCCESS STATUS_INVALID_PARAMETER STATUS_OB J ECT_N AM E_l N VALID STATUS_OB J ECT_N AM E_NOT_FOU N D

STATUSOBJ ECT_PATH_SYNTAX_BAD

STATUS_PRIVILEGE_NOT_HELD

STATUS_INSUFFICIENT_RESOURCES

CommitT ransaction (INPHANDLETransactionHandle INULONGCommitOptionsOptional);

[0087] Esta rotina requisita que o Transaction associado com o TransactionHandle seja entregue. Qualquer identificador de transação que foi aberto ou criado pode ser entregue com o acesso Transac-tion_Commit Desejado. Desde que não exista restrição afirmando que somente o criador de uma transação é permitido de entregar a mesma.

[0088] Se o Transaction em questão não emitiu anteriormente uma requisição PrepareEnlistment, então um protocolo de entrega de duas fases pode ser iniciado em todos os RMs incluídos. Esta chamada pode ser vista como uma requisição de entrega de fase única sendo emitida pelo cliente.

[0089] Este roteamento não é chamado se o Transaction tiver sido anteriormente preparado via o PrepareEnlistment. Somente um RM que chamou o PrepareEnlistment pode resolver o estado da transação utilizando o SuperiorCommitTransaction.

Argumentos: TransactionHandle: fornece um identificador indicando o Transaction a ser entregue; e CommitOptions: O Transaction COMMIT RETAINING será entregue. Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TRANSACTION_ABORTED

RolIbackT ransaction (INPHANDLETransactionHandle IN SAVEPOINT SavePoi ntOptional, INROLLBACK_REASON RolIbackReason Optional);

Esta rotina requisita que o Transaction associado com o Transactio-nHandle seja revertido. A reversão pode ser uma reversão parcial caso o SavePoint opcional seja especificado e seja um ponto de salvamento válido. Um argumento SavePoint NULL indica que o Transaction deve ser completamente revertido ou cancelado. Uma estrutura Roll-backReason opcional pode ser fornecida; esta será retida no objeto Transaction e pode ser recuperada pelos participantes da transação interessados via uma chamada para GetlnformationTransaction. Argumentos: TransactionHandle: Fornece um identificador indicando que o Transaction seja revertido;

SavePoint: Fornece um nome do SavePoint, indicando até quanto um estado de uma transação deve ser revertido; e RolIbackReason: Fornece uma razão da reversão Valores de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJ N VALI D_H AN DLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TRANSACTION_COMMITTED

SavePointT ransaction (INPHANDLETransactionHandle, IN U LON G Savepoi ntFlagsOptional, OUT LPSAVEPOINTSavePoint);

[0090] Esta rotina requisita que um "ponto de salvamento" seja gerado para um Transaction associado com TransactionHandle; este pon- to de salvamento é utilizado como um alvo para requisições de reversão subsequentes.

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual um SavePoint deve ser estabelecido;

SavepointFlags: opcionalmente fornece um conjunto de indicadores que afetam a geração do ponto de salvamento; e SavePoint: Fornece um ponteiro para uma localização onde um identificador do Savepoint é armazenado.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TRANSACTION_COMMITTED

STATUS_TM_TRANSACTION_ABORTED

Query InformationT ransaction (INHANDLETransactionHandle, INTRANSACTIONINFORMATIONCLASSTransactionln- formationClass, OUT PVOlDTransactionlnformation, IN ULONGTransactionlnformationLength, OUTPULONGReturnLength Optional);

[0091] Esta rotina retorna informações requisitadas sobre o objeto Transaction representado por TransactionHandle.

Argumentos: TransactionHandle: Fornece um identificador indicando uma Transaction para a qual a informação está sendo requisitada;

TransactionlnformationClass: Indica qual classe de informação sobre o objeto Transaction está sendo requisitada;

TransactionInformation: Fornece um ponteiro para uma memória intermediária onde a informação de transação requisitada é armazenada;

TransactionlnformationLength: Indica o tamanho da memória intermediária apontada pelo Transactionlnformation; e ReturnLength: Fornece um ponteiro para a localização que irá receber o tamanho da informação gravada junto à memória intermediária Transactionlnformation.

Valor de Retorno STATUS_SUCCESS STATUS_ACCESS_DENIED STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES STATUSJ N VALI D_l N FO_CLASS STATUS_INFO_LENGTH_MISMATCH SetlnformationT ransaction (INHANDLETransactionHandle, INTRANSACTION_INFORMATION_CLASSTransactionln-formationClass, IN PVOlDTransactionlnformation, IN ULONGTransac-tionlnformationLength);

[0092] Esta rotina estabelece a informação requisitada sobre o objeto Transaction representado por TransactionHandle.

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction cuja informação será modificada;

TransactionlnformationClass: Indica qual classe de informação sobre o objeto Transaction está sendo requisitada;

Transactionlnformation: Fornece um ponteiro para uma memória intermediária onde a informação de transação requisitada é armazenada;

TransactionlnformationLength: Indica um tamanho da memória intermediária apontada pelo Transactionlnformation; e ReturnLength: Fornece um ponteiro para uma localização que irá receber o tamanho da informação gravada junto à memória intermediária T ransaction Information.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUSJNSUFFICIENTRESOURCES

STATUS_INVALID_INFO_CLASS

STATUS_INFO_LENGTH_MISMATCH

[0093] O que se segue inclui uma descrição mais detalhada das APIs listadas acima, para implementar operações em objetos núcleo RMO. As descrições incluem uma descrição da rotina, dos argumentos correspondentes e dos valores de retorno.

CreateResourceManager (OUT PHANDLEResourceManagerHandle, IN ACCESS_M ASK DesiredAccess Optional, IN POB J ECT_ATTRI BUTES ObjectAttributes, IN ULONGCreateOptions Optional, INRM_NOTIFICATION_ROUTINENotificationRoutine Optional);

[0094] Esta rotina cria um novo objeto ResourceManager para representar um recurso.

[0095] Um objeto ResourceManager também serve como um ponto final para notificações TM com respeito aos Transactions que o RM uniu; um RM requisita estas notificações por chamar GetNotification- ResourceManager.

[0096] Um ResourceManager é normalmente um objeto persistente, isto é, o objeto deve ser novamente aberto e executado recuperação após cada falha (sistema ou RM). Uma versão transitória de um objeto ResourceManager pode ser criada por especificar a opção RESOURCEMANAGER_NO_RECOVERY. Um RM transitório não é obrigado ou permitido de executar a recuperação. A opção do RM não recuperável permite à uma aplicação ou à um RM receber notificações a cerca do progresso da transação (por exemplo, PREPREPARE, PREPARE, COMMIT) sem ser requerido de implementar toda a complexidade de registrar preparos e executar a recuperação.

Argumentos: ResourceManagerHandle: Fornece um ponteiro para a localização que irá receber um identificador para o novo ResourceManager;

DesiredAccess: Fornece uma máscara especificando um nível de acesso desejado. Escolhas de máscara de acesso válidas são: SYNCHRONIZE: para sincronizar operações em um identificador, RESOURCE MANAGER_DESTROY: para destruir este gerenciador de recurso, RESOURCE_MANAGER_READ_ATTRIBUTES: para ler atributos associados com um gerenciador de recurso, RESOURCE MANAGER_WRITE_ATTRIBUTES: para gravar atributos associados com um gerenciador de recurso;

ObjectAttributes: Especifica os atributos para o novo objeto RM; isto inclui o nome do RM;

CreateOptions: Especifica opções para o objeto criado; RESOURCEMANAGER_NO_RECOVERY: O objeto Resou- rceManager não é persistente e não executa a recuperação; RESOURCEMANAGER COMMUNICATION: O Resource-Manager sabe como se comunicar com outros computadores. O Re-sourceManager pode ser utilizado para conduzir ou reter as transações; RESOURCEMANAGER_CLUSTER_RECOVERY: O Re-sourceManager sabe como ler / distribuir resultados para registrar arquivos que podem ter falhado através dos outros nós no agrupamento. O ResourceManager pode ser utilizado para recuperar transações em um agrupamento; e NotificationRoutine: Especifica uma rotina de notificação a ser chamada quando as notificações estiverem disponíveis para este ResourceManager.

Valor de Retorno: STATUS_SUCCESS

STATUS_INVALID_PARAMETER

STATUS_OBJECT_NAME_COLLISION

ST ATU S_0 B J ECTN AM E_l N VALID

STATUS_PRIVILEGE_NOT_HELD

STATUSJNSUFFICIENTRESOURCES

OpenResourceManager (OUT PHANDLEResourceManagerHandle, IN ACC ESS_M AS K Desi red Access Optional, INPOBJECTATTRIBUTESObjectAttributes, IN U LON G OpenOptions Optional, INRMNOTIFICATIONROUTINENotificationRoutine Optional).

[0097] Esta rotina abre um objeto ResourceManager existente pelo nome. Se um objeto ResourceManager alvo for persistente porém não correntemente aberto, o objeto está inicialmente em um estado de "recuperação" e deve ser recuperado; após a recuperação estar completa, RecoveryCompleteResourceManager deve ser chamado. Argumentos: ResourceManagerHandle: Fornece um ponteiro para a localização que irá receber um identificador para o objeto ResourceManager existente;

DesiredAccess: Fornece a máscara especificando o acesso desejado para este objeto;

ObjectAttributes: Especifica os atributos para o novo objeto RM;

OpenOptions: Especifica opções para o objeto. Opções válidas incluem: RESOURCE_MANAGER_DETAILED_RECOVERY_NOTIFICATIONS

[0098] O gerenciador de recurso recebe notificações de recuperação detalhadas (com informações adicionais sobre os pontos finais de comunicação) ao invés de notificações de recuperação normais; e [0099] NotificationRoutine: Especifica uma rotina de notificação que será chamada quando as notificações estiverem disponíveis para este ResourceManager.

Valor de Retorno: STATUS_SUCCESS

STATUSJ N VALI D_PARAM ETER

ST ATU S_0 B J ECT_N AM E_l N VALID

STATUS_OBJECT_NAME_NOT_FOUND

STATUS_OBJ ECT_PATH_SYNTAX_BAD

STATUS_PRIVILEGE_NOT_HELD

STATUS_INSUFFICIENT_RESOURCES

DestroyResourceManager (INPHANDLEResourceManagerHandle);

[00100] Esta rotina destrói um objeto ResourceManager, causando que ele não seja mais persistente.

Argumentos: ResourceManagerHandle: fornece um identificador indicando o objeto ResourceManager a ser destruído.

Valor de Retorno: STATUS_SUCCESS

STATUSACCESSDENIED

STATUSJNVALIDHANDLE

STATUSINSUFFICIENTRESOURCES STATUS_TM_NEEDS_RECOVERY.

QuerylnformationResourceManager (IN HANDLE ResourceManagerHandle, INRESOURCEMANAGERINFORMATIONCLASS

ResourceManagerlnformationClass, OUT PVOlDResourceManagerlnformation, INULONG

ResourceManagerlnformationLength, OUTPULONG ReturnLengthOptional).

[00101] Esta rotina retorna a informação requisitada sobre o RMO representado por ResourceManagerHandle.

Argumentos: ResourceManagerHandle: Fornece um identificador indicando o ResourceManager para o qual a informação está sendo requisitada;

ResourceManagerlnformationClass: indica qual classe de informação sobre o objeto ResourceManager está sendo requisitada;

ResourceManagerlnformation: Fornece um ponteiro para uma memória intermediária onde a informação do ResourceManager requisitada será armazenada;

ResourceManagerlnformationLength: Indica o tamanho da memória intermediária apontada pelo ResourceManagerlnformation; e ReturnLength: Fornece um ponteiro para a localização para receber um tamanho da informação gravada junto à memória intermediária ResourceManagerlnformation.

Valor de Retorno: STATUS_SUCCESS

STATUSACCESSDENIED

STATUSJNVALIDHANDLE

STATUSINSUFFICIENTRESOURCES

STATUSINVALIDINFOCLASS

STATUS_INFO_LENGTH_MISMATCH

SetlnformationResourceManager (INHANDLEResourceManagerHandle, IN RESOURCEMANAGERINFORMATIONCLASS ResourceManagerlnformatioNCIass, IN PVOID ResourceManagerlnformation, INULONGResourceManagerlnformationLength);

[00102] Esta rotina estabelece a informação requisitada sobre o RMO representado por ResourceManagerHandle.

Argumentos: ResourceManagerHandle: Fornece um identificador indicando o ResourceManager para o qual a informação está sendo modificada;

ResourceManagerlnformationClass: indica qual classe de informação sobre o objeto ResourceManager está sendo requisitada;

ResourceManagerlnformation: Fornece um ponteiro para uma memória intermediária onde a informação do ResourceManager requisitada é armazenada; e ResourceManagerlnformationLength: Indica o tamanho da memória intermediária apontada pelo ResourceManagerlnformation; Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_INVALID_INFO_CLASS STATUS_INFO_LENGTH_MISMATCH.

CreateEnlistment (INPHANDLEResourceManagerHandle, INPHANDLETransactionHandle, INNOTIFICATION_MASKNotificationMask, INLPVOlDTransactionKeyOptional);

[00103] Esta rotina causa que o RMO "se una" à uma transação particular e receba notificações relacionando-se à mesma.

[00104] A chamada CreateEnlistment não se altera e um RM pode chamar esta rotina várias vezes de modo a alterar sua Notification-Mask ou TransactionKey. As chamadas subsequentes para CreateEnlistment substituem uma máscara de notificação e a chave de transação sem criar uma nova inclusão na transação.

[00105] NotificationMask pode ser utilizada para requisitar que as notificações sejam recebidas várias vezes. Por exemplo, um RM recebendo uma notificação PREPREPARE pode requisitar outra por chamar JoinTransaction e especificar o indicador PREPREPARE. Assim, um RM pode receber várias requisições PREPREPARE. Tais requisições podem ser recusadas, o que pode ser desejável se a transação tiver contiunado passando pelo ponto em que a notificação requisitada teria sido recebida. Por exemplo, requisitar um PREPREPARE quando algum RM já tiver sido notificado para PREPARE pode não ser permi- tido.

Argumentos: ResourceManagerHandle: Fornece um identificador para um RM receber notificações a cerca do Transaction especificado;

TransactionHandle: Fornece um identificador para o Transaction junto ao qual o RM deseja se unir;

NotificationMask: especifica as notificações que o RM gostaria de receber com respeito à este Transaction. Máscaras válidas são como se segue e podem ser unidas com um operador OR: TRANSACTION_NOTIFY_MASK_RM: Notificações comuns desejadas por um RM (PREPARE, COMMIT, ROLLBACK, SAVEPOINT), TRANSACTION_NOTIFY_MASK_CRM: Notificações comuns desejadas por um CRM ou TM Superior (PrePrepare_Complete, PrepareComplete. CommitComplete, RolIbackComplete, Saveback-Complete), TRANSACTION_NOTIFY_PREPREPARE: Notificação para PrePrepare, TRANSACTION_NOTIFY_PREPARE: Notificação para PREPARE, TRANSACTION_NOTIFY_COMMIT: Notificação para COMMIT, TRANSACTION_NOTIFY_ROLLBACK: Notificação para ROLLBACK, TRANSACTION_NOTIFY_PREPREPARE_COMPLETE: Notificação de que PREPREPARE está completo, TRANSACTION_NOTIFY_PREPARE_COMPLETE: Notificação de que PREPARE está completo, TRANSACTION_NOTIFY_COMMIT_COMPLETE: Notificação de que COMMIT está completo, TRANSACTION_NOTIFY_ROLLBACK_COMPLETE: Notifi- cação de que ROLLBACK está completo, e TRANSACTION_NOTIFY_SAVEPOINT_COMPLETE: Notificação de que SAVEPOINT está completo; e TransactionKey: Especifica um valor de ponteiro opaco que o RM gostaria de receber junto com quaisquer notificações para este Transaction. O RM pode utilizar este para associar notificações com algum objeto no espaço de endereço RM, assim prevenindo a necessidade de executar uma busca cada vez que ocorrer uma notificação. Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_PARAMETER

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES STATUS_TM_TOO_LATE.

GetNotificationResourceManager (INPHANDLEResourceManagerHandle, INPTRANSACTION_NOTIFICATIONTransactionNotifica- tion, INPLARGEJNTEGERTimeout Optional);

[00106] Esta rotina consulta e retorna uma notificação RM, se alguma estiver disponível.

Argumentos: ResourceManagerHandle: Fornece um identificador indicando o ResourceManager para o qual uma notificação deve ser retornada;

TransactionNotification: Fornece um ponteiro para uma estrutura TRANSACTIONNOTIFICATION a ser preenchida com a primeira notificação disponível; e Timeout: Fornece o tempo até o qual o chamador deseja bloquear enquanto esperando que uma notificação se torne disponível. Se nenhuma estiver disponível quando este tempo de espera expirar, o chamador retorna com STATUS_TIMEOUT.

Valor de retorno: STATUS_SUCCESS

STATUS_TIMEOUT

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

[00107] O que se segue inclui uma descrição mais detalhada das APIs listadas acima, para implementar operações em objetos núcleo TX por objetos núcleo RMO após se unir com uma transação. As descrições incluem uma descrição da rotina, dos argumentos correspondentes e dos valores de retorno.

PrePrepareComplete (INPHANDLEEnlistmentHandle);

[00108] Esta rotina indica que o RM completou o processamento de preparo anterior (também conhecido como "PhaseO") de um Transac-tion como requisitado pelo KTM

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual a operação de preparo anterior foi completada.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

PrepareComplete (INPHANDLEEnlistmentHandle);

[00109] Esta rotina indica que o RM completou a preparação de um Transaction como requisitado pelo KTM

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual a operação de preparo foi completada.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

RolIbackComplete (INPHANDLEEnlistmentHandle);

[00110] Esta rotina indica que o RM de forma bem sucedida completou a reversão do trabalho executado por um Transaction como requisitado. Se o RM não estiver apto a de forma bem sucedida reverter o Transaction como requisitado, ele deve emitir uma requisição para uma reversão completa via RolIbackTransaction.

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual a operação de reversão foi completada.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

CommitComplete (INPHANDLEEnlistmentHandle);

[00111] Esta rotina indica que o RM completou a entrega do traba- Iho executado por um Transaction como requisitado.

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual a operação de entrega foi completada.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

[00112] Em adição, as rotinas de propagação podem ser proporcionadas para os objetos núcleo. Exemplos destas rotinas se seguem. RegisterProtocolAddressInformation (IN HANDLEResourceManager, IN PROTOCOLJDProtocolld, IN ULONGProtocolInformationSize, IN PVOlDProtocolInformationOptional).

[00113] Esta rotina registra um gerenciador de recurso como um gerenciador de recurso de comunicações para um protocolo particular. Ela também associa uma bolha de informações com este protocolo. Somente um gerenciador de recurso pode registrar-se para um protocolo em uma dada máquina.

Argumentos: ResourceManager: Fornece um identificador para o gerenciador de recurso que nós estamos registrando: Protocolld: o GUID identificando o protocolo; ProtocolInformationSize: O tamanho de ProtocolInformation; ProtocolInformation: bolha opcional para associar-se com este protocolo;

Valores de retorno STATUS_SUCCESS STATUSJNVALIDHANDLE MarshallT ransaction (INPHANDLETransactionHandle, INULONGNumberOfProtocolos, IN PROT OCOLID Protocol Array, INULONGBufferLength, INPVOlDBuffer, OUTPULONG BufferUsedOptional).

[00114] Esta rotina requisita que uma representação do Transaction correspondendo ao TransactionHandle seja serializada em uma memória intermediária.

Argumentos: TransactionHandle: Fornece um identificador indicando o Transaction para o qual a operação de entrega foi completada;

NumberOfProtocois: Indica o tamanho do vetor de protocolos;

ProtocolArray: Um vetor de PROTOCOL IDs (GUIDs) que especifica os protocolos que podem ser utilizados para conduzir esta transação. O vetor deve ser ordenado por preferência - o primeiro protocolo no vetor é o protocolo preferido, o segundo protocolo é o segundo protocolo mais preferido, etc,;

BufferLength: Fornece o tamanho da Memória intermediária que está disponível;

Buffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação deve ser armazenada; e BufferUsed: Fornece um ponteiro para uma localização onde os bytes reais gravados na memória intermediária devem ser armazenados.

Valores de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

GetProtocolAddressInformation (INULONGAddressBufferSize, OUTPVOlDAddressBuffer, OUTPULONGAddressBufferUsedOptional).

[00115] Esta rotina requisita que a informação representando todos os protocolos registrados na máquina seja serializada no AddressBuf-fer. Esta informação pode então ser passada para outra maquina e utilizada como um argumento para PushTransaction, para estender uma transação para a máquina na qual o Addresslnformation foi gerado. Argumentos: AddressBufferSize: Fornece o tamanho da memória intermediária que está disponível.

AddressBuffer: Fornece o tamanho da memória intermediária que está disponível.

AddressBufferUsed: Fornece um ponteiro para uma localização da memória intermediária onde a serialização da transação é armazenada.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

PullTransaction (OUTPHANDLETransactionHandle, INULONGNumberOfProtocoIs, IN PCRM_PROT OCOL_l D Protocol Array, INULONGBufferLength, INPVOlDBuffer).

[00116] Esta rotina requisita que a transação representada pela se-rialização na memória intermediária seja feita disponível pelo gerenciador de transação. Um identificador para o novo objeto Transaction é retornado, após a transação ter sido de forma bem sucedida propagada por um dos gerenciadores de recurso registrados.

Argumentos: TransactionHandle: Fornece um ponteiro para onde o identificador representando o novo Transaction deve ser armazenado;

NumberOfProtocolos: Indica o tamanho do vetor de protocolos;

ProtocolArray: Um vetor de PROTOCOL IDs (GUIDs) que especifica os protocolos que podem ser utilizados para conduzir esta transação. O vetor deve ser ordenado por preferência - o primeiro protocolo na série é o protocolo preferido, o segundo protocolo é segundo protocolo mais preferido, etc.;

BufferLength: Fornece o tamanho da memória intermediária que está disponível;

Buffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação é armazenada.

Valores de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

PushTransaction (INHANDLETransactionHandle, INULONGNumberOfProtocoIs, IN PCRM_PROTOCOL_ID ProtocolArray, IN U LON G Desti nation I nfoLength, IN PVOID Desti nation I nfo, INULONGResponseBufferLength, OUTPVOlDResponseBuffer, OUTPULONGResponseBufferUsedOptional, OUTPULONG PushCookieOptional).

[00117] Esta rotina requisita que a transação seja propagada para a máquina de destinação utilizando a propagação do estilo de extensão. Os protocolos serão utilizados na ordem em que eles são listados no ProtocolArray, até um ser bem sucedido. Se nenhum protocolo for bem sucedido na propagação para a máquina de destinação, a rotina retornará falha.

Argumentos: TransactionHandle: Fornece um ponteiro para o objeto de transação que deve ser propagado para a máquina remota;

Desti nation I nfoLength: Fornece o tamanho do Desti nation In-foLength que está disponível;

Destinationlnfo: Fornece um ponteiro para uma memória intermediária onde a informação de "ponto final" para o destino é armazenada. Esta pode ser a saída recebida a partir de uma chamada para GetProtocalAddressInformation na máquina de destinação;

ResponseBufferLength: Fornece o tamanho do Response-Buffer que está disponível;

ResponseBuffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação é armazenada; e PushCookie: Fornece um ponteiro para uma memória intermediária cujo cookie representando esta requisição de extensão será armazenado.

Valor de retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

GetPushT ransactionBuffer (INHANDLETransactionHandle, INULONGPushCookie, INULONGResponseBufferLength, OUTPVOlDResponseBuffer, OUTPULONGResponseBufferUsed Optional).

[00118] Esta chamada é utilizada para recuperar a saída de uma chamada para PushTransaction, no evento em que a chamada inicial para PushTransaction recebeu um código de retorno STATUS_BUFFER_TOO_SMALL. Neste evento, o chamador é para chamar GetPushTransactionBuffer e passa um tamanho de memória intermediária suficiente.

Argumentos: TransactionHandle: Fornece um ponteiro para a localização onde o identificador representando o novo Transaction é para ser armazenado;

BufferLength: Fornece o tamanho da memória intermediária que está disponível; e Buffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação é armazenada.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

PropagationComplete (IN HANDLEEnlistmentHandle, INULONGRequestCookie, INULONGBufferLength, INPVOlDBuffer).

[00119] Esta rotina é chamada por um CRM após ele ter de forma bem sucedida completado a propagação de uma transação. Argumentos: TransactionHandle: Fornece um ponteiro para a localização onde o identificador representando o novo Transaction é para ser armazenado;

RequestCookie: Fornece o RequestCookie que foi recebido no argumento de notificação PROPAGATE original, para indicar qual requisição foi completada;

BufferLength: Fornece o tamanho da Memória intermediária que está disponível; e Buffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação é armazenada.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

PropagationFailed (INHANDLEResourceManagerHandle, IN U LO N G Req uestCooki e, INSTATUSPropStatus).

Um CRM utiliza esta rotina para indicar que ele falhou ao propagar a transação como requisitado;

Argumentos: TransactionHandle: Fornece um ponteiro para a localização onde o identificador representando a nova transação é para ser arma- zenado;

BufferLength: Fornece o tamanho da memória intermediária que está disponível; e Buffer: Fornece um ponteiro para uma memória intermediária onde a serialização da transação é armazenada.

Valor de Retorno: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUSJNSUFFICIENTRESOURCES.

Ambiente de computação ilustrativo [00120] A FIG. 9 ilustra um ambiente de computador geral 900, o qual pode ser utilizado para implementar as técnicas descritas aqui dentro. O ambiente de computador 900 é somente um exemplo de um ambiente de computação e não é pretendido de sugerir qualquer limitação quanto ao escopo do uso ou funcionalidade das arquiteturas de computador e de rede. Nem deve o ambiente de computador 900 ser interpretado como possuindo qualquer dependência ou requerimento relacionando-se à qualquer um ou à combinação dos componentes ilustrados no ambiente de computador ilustrativo 900.

[00121] O ambiente de computador 900 inclui um dispositivo de computação de propósito geral na forma de um computador 902. Os componentes do computador 902 podem incluir, mas não estão limitados à um ou mais processadores ou unidades de processamento 904, à memória do sistema 906 e ao barramento do sistema 908 que acopla vários componentes do sistema incluindo o processador 904 com a memória do sistema 906.

[00122] O barramento do sistema 908 representa um ou mais dentre vários tipo de estruturas de barramento, incluindo um barramento de memória ou controlador de memória, um barramento periférico, uma porta de gráficos acelerados e um processador ou barramento local utilizando qualquer uma dentre uma variedade de arquiteturas de barramento. À título de exemplo, tais arquiteturas podem incluir um barramento da Arquitetura de Padrão da Indústria (ISA), um barramento da Arquitetura de Micro Canal (MCA), um barramento ISA Aperfeiçoado (EISA), um barramento local da Associação de Padrões de Componentes Eletrônicos de Vídeo (VESA), um barramento da Interconexão de Componente Periférico (PCI) também conhecido como um barramento Mezanino, um barramento PCI expresso, um Barramento Serial Universal (USB), um barramento Digital Seguro (SD) ou um IEEE 1394, isto é, barramento FireWire.

[00123] O computador 902 pode incluir uma variedade de meios legíveis por computador. Tais meios podem ser qualquer meio disponível que seja acessível pelo computador 902 e inclua tanto o meio volátil e não volátil como o meio removível e não removível.

[00124] A memória do sistema 906 inclui o meio legível por computador na forma de memória volátil, tal como a memória de acesso ran-dômico (RAM) 910; e / ou a memória não volátil, tal como a memória somente leitura (ROM) 912 ou RAM flash. O sistema de entrada / saída básico (BIOS) 914, contendo as rotinas básicas que ajudam a transferir informações entre os elementos dentro do computador 902, tal como durante a inicialização, é armazenado na ROM 912 ou na RAM flash. A RAM 910 tipicamente contém dados e / ou módulos de programa que são imediatamente acessíveis e / ou presentemente operados pela unidade de processamento 904.

[00125] O computador 902 também pode incluir outros meios de armazenamento do computador removíveis / não removíveis, voláteis / não voláteis. À título de exemplo, a FIG. 9 ilustra o controlador de disco rígido 916 para leitura e gravação junto à um meio magnético não removível, não volátil (não apresentado), o controlador de disco magnéti- co 918 para leitura e gravação junto à um disco magnético removível, não volátil 920 (por exemplo, um "disco flexível") e um controlador de disco ótico 922 para leitura e / ou gravação junto a um disco ótico removível, não volátil 924 tal como um CD-ROM, DVD-ROM ou outro meio ótico. Cada um dentre o controlador de disco rígido 916, do controlador de disco magnético 918 e do controlador de disco ótico 922 está conectado com o barramento do sistema 908 por uma ou mais interfaces de meio de dados 925. De forma alternativa, o controlador de disco rígido 916, o controlador de disco magnético 918 e o controlador de disco ótico 922 podem ser conectados com o barramento do sistema 908 por uma ou mais interfaces (não apresentadas).

[00126] Os controladores de disco e seus meios legíveis por computador associados proporcionam o armazenamento não volátil das instruções legíveis por computador, das estruturas de dados, dos módulos de programa e de outros dados para o computador 902. Apesar do exemplo ilustrar um disco rígido 916, o disco magnético removível 920 e o disco ótico removível 924, é apreciado que outros tipos de meios legíveis por computador que possam armazenar dados que sejam acessíveis por um computador, tal como cassetes magnéticos ou outros dispositivos de armazenamento magnético, cartões de memória flash, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento ótico, memórias de acesso randômico (RAM), memórias somente leitura (ROM), memória somente leitura programável que pode ser eletricamente apagada (EEPROM) e coisa parecida, também podem ser utilizados para implementar o sistema e ambiente de computação ilustrativos.

[00127] Qualquer número de módulos de programa podem ser armazenados no disco rígido 916, no disco magnético 920, no disco ótico 924, na ROM 912 e / ou na RAM 910, incluindo à título de exemplo, o sistema operacional 926, um ou mais programas de aplicação 928, ou- tros módulos de programa 930 e dados de programa 932. Cada um do tal sistema operacional 926, do um ou mais programas de aplicação 928, dos outros módulos de programa 930 e dos dados de programa 932 (ou alguma combinação dos mesmos) pode desempenhar o papel de transações, de acordo com as modalidades ilustrativas descritas acima, para implementar todos ou parte dos componentes residentes que suportam o sistema de arquivo distribuído.

[00128] Um usuário pode entrar com comandos e informações dentro do computador 902 via dispositivos de entrada tal como teclado 934 e um dispositivo de apontamento 936 (por exemplo, um "mouse"). Outros dispositivos de entrada 938 (não apresentados de forma específica) podem incluir um microfone, joystick, plataforma de jogo, antena de satélite, portal serial, digitalizador e / ou coisa parecida. Estes e outros dispositivos de entrada estão conectados com a unidade de processamento 904 via as interfaces de entrada / saída 940 que estão acopladas com o barramento do sistema 908, mas podem ser conectadas por outras estruturas de interface e de barramento, tal como por uma porta paralela, porta de jogo ou um barramento serial universal (USB).

[00129] O monitor 942 ou outro tipo de dispositivo de exibição também pode ser conectado com o barramento do sistema 908 via uma interface tal como o adaptador de vídeo 944. Em adição ao monitor 942, outros dispositivos periféricos de saída podem incluir componentes tal como alto-falantes (não apresentados) e a impressora 946, a qual pode ser conectada com o computador 902 via as interfaces de E/S 940.

[00130] O computador 902 pode operar em um ambiente em rede utilizando conexões lógicas com um ou mais computadores remotos, tal como o dispositivo de computação remoto 948. À título de exemplo, o dispositivo de computação remoto 948 pode ser um PC, computador portátil, um servidor, um roteador, um computador da rede, um disposi- tivo par ou outro nó comum da rede e coisa parecida. O dispositivo de computação remoto 948 é ilustrado como um computador portátil que pode incluir vários ou todos os elementos e características descritos aqui dentro relativos ao computador 902. De forma alternativa, o computador 902 também pode operar em um ambiente que não seja em rede.

[00131] As conexões lógicas entre o computador 902 e o computador remoto 948 são descritas como uma rede de área local (LAN) 950 e uma rede de área ampla geral (WAN) 952. Tais ambientes em rede são comuns em escritórios, redes de computador de grandes empresas, nas intranets e na Internet.

[00132] Quando implementado em um ambiente em rede LAN, o computador 902 é conectado com a rede local 950 via a interface ou adaptador de rede 954. Quando implementado em um ambiente em rede WAN, o computador 902 tipicamente inclui o modem 956 ou outro dispositivo para estabelecer comunicações através da rede ampla 952. O modem 956, o qual pode ser interno ou externo em relação ao computador 902, pode ser conectado com o barramento do sistema 908 via as interfaces de E/S 940 ou por outros mecanismos apropriados. As conexões de rede ilustradas são ilustrativas e outro dispositivo para estabelecer pelo menos uma ligação de comunicação entre os computadores 902 e 948 pode ser empregado.

[00133] Em um ambiente em rede, tal como este ilustrado com o ambiente de computação 900, os módulos de programa descritos relativos ao computador 902, ou partes dos mesmos, podem ser armazenados em um dispositivo de armazenamento em memória remota. À título de exemplo, os programas de aplicação remota 958 residem em um dispositivo de memória do computador remoto 948. Para propósitos de ilustração, as aplicações ou programas e outros componentes de programa executáveis, tal como o sistema operacional, são ilustra- dos aqui dentro como blocos distintos, apesar de ser reconhecido que tais programas e componentes residem em vários momentos em diferentes componentes de armazenamento do dispositivo de computação 902 e são executados pelo menos por um processador de dados do computador.

[00134] Vários módulos e técnicas podem ser descritos aqui dentro no contexto geral de instruções executáveis por computador, tal como módulos de programa, executados por um ou mais computadores ou outros dispositivos. Geralmente, os módulos de programa incluem rotinas, programas, objetos, componentes, estruturas de dados, etc. para executar tarefas particulares ou implementar tipos de dados abstratos particulares. Estes módulos de programa e coisa parecida podem ser executados como código nativo ou podem ser transferidos e executados, tal como em uma máquina virtual ou em outro ambiente de execução de compilação instantânea. Tipicamente, a funcionalidade dos módulos de programa pode ser combinada ou distribuída como desejado nas várias modalidades.

[00135] Uma implementação destes módulos e técnicas pode ser armazenada ou transmitida através de alguma forma de meio legível por computador. Os meios legíveis por computador podem ser qualquer meio disponível que possa ser acessado por um computador. À título de exemplo e não de limitação, os meios legíveis por computador podem compreender o "meio de armazenamento do computador" e os "meios de comunicação".

[00136] O "meio de armazenamento do computador" inclui o meio volátil e não volátil, removível e não removível implementado em qualquer método ou tecnologia para armazenamento de informações tal como instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados. O meio de armazenamento do computador inclui, mas não está limitado à RAM, ROM, EEPROM, memó- ria flash ou à outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento ótico, cassetes magnéticos, fita magnética, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético ou à qualquer outro meio que possa ser utilizado para armazenar a informação desejada e o qual possa ser acessado por um computador.

[00137] O "meio de comunicação" tipicamente incorpora instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados em um sinal de dados modulado, tal como uma onda portadora ou outro mecanismo de transporte. Os meios de comunicação também incluem qualquer meio de distribuição de informação. O termo "sinal de dados modulado" significa um sinal que possui uma ou mais de suas características estabelecidas ou alteradas de modo a codificar a informação no sinal. Somente como um exemplo não limitativo, os meios de comunicação incluem meios com fios tal como uma rede com fios ou conexão direta com fios e meios sem fios tal como acústico, RF, infravermelho e outros meios sem fios. Combinações dentre qualquer um dos acima também estão incluídas dentro do escopo dos meios legíveis por computador.

[00138] Foi feita referência por toda esta especificação à "uma certa modalidade", "uma modalidade" ou à "uma modalidade ilustrativa" significando que um aspecto, estrutura ou característica particular descrita está incluída em pelo menos uma modalidade da presente invenção. Assim, o uso de tais frases pode se referir à mais do que somente uma modalidade. Adicionalmente, os aspectos, estruturas ou características descritas podem ser combinadas de um modo adequado em uma ou mais modalidades.

[00139] Entretanto, os com conhecimento na técnica relevante podem reconhecer que a invenção pode ser praticada sem um ou mais dos detalhes específicos ou com outros métodos, recursos, materiais, etc. Em outros exemplos, estruturas, recursos ou operações bem conhecidas não foram apresentados ou descritos em detalhes meramente para evitar obscurecer aspectos da invenção.

[00140] Enquanto que as modalidades e aplicações ilustrativas da presente invenção foram ilustradas e descritas, é para ser entendido que a invenção não está limitada à configuração e aos recursos precisos descritos acima. Várias modificações, alterações e variações aparentes para os com conhecimento na técnica podem ser feitas na disposição, nas operações e nos detalhes dos métodos e sistemas da presente invenção revelados aqui dentro sem se afastar do escopo da invenção reivindicada.

REIVINDICAÇÕES

Claims (15)

1. Sistema para suportar operações de arquivo remoto transacionadas entre um dispositivo local e um dispositivo remoto, o sistema sendo CARACTERIZADO por compreender: um gerenciador de transação; e um redirecionador para receber uma requisição para executar uma operação de arquivo em um arquivo residindo no dispositivo remoto, os dispositivos locais e remotos conectados com uma rede, em que o redirecionador é para enviar a requisição para o dispositivo remoto através da rede dentro de uma transação; em que o sistema compreende meio para executar etapas, em que uma aplicação gerando os dados faz uma chamada ou emite uma requisição para entregar a transação, e esta chamada ou requisição é passada para o gerenciador de transação; em que, em resposta, o gerenciador de transação gera uma notificação de preparo anterior; em que o redirecionador recebe a notificação de preparo anterior a partir do gerenciador de transação e, em resposta, atualiza os dados para o servidor via a rede, e em que o servidor passa os dados para um NTFS; em que um gerenciador de transação do servidor sinaliza ao redirecionador quando a operação de preparo anterior está completa; em que o redirecionador recebe uma notificação de preparo a partir do gerenciador de transação e envia uma mensagem de notificação de preparo para o servidor em resposta à notificação de preparo, a qual é passada para o gerenciador de transação do servidor, em que o gerenciador de transação do servidor passa a notificação de preparo para o NTFS; e em que a notificação de preparo causa que o cliente e o servidor armazenem os dados de um modo que permita aos dados serem entregues ou revertidos, em que os dados são então processados utilizando operações de entrega de duas fases.

2. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o gerenciador de transação não é integrado em um sistema de arquivos.

3. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o redirecionador é para determinar se um FCB existente que está associado com uma transação neutra pode ser utilizado para a requisição.

4. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o redirecionador, quando determinando se um FCB existente pode ser utilizado para a requisição, é para comparar um nome de caminho e contexto de transação para a requisição com um nome de caminho associado com o FCB existente.

5. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o gerenciador de transação é um gerenciador de transação de nível núcleo.

6. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o redirecionador é para de forma seletiva indicar na requisição que o dispositivo remoto deve sinalizar para a máquina local em resposta à uma operação de arquivo sendo executada no arquivo que não foi requisitado pelo redirecionador.

7. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o redirecionador envia a transação com a requisição utilizando um protocolo baseado em um protocolo de bloco de mensagem do servidor (SMB).

8. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que o protocolo suporta operações de arquivo remoto não transacionadas.

9. Método para implementar uma operação de arquivo remoto transacionada em um dispositivo local, o método sendo CARACTERIZADO por compreender: receber uma requisição para uma operação de arquivo remoto transacionada compreendendo: recuperar uma transação; conduzir a transação; enviar a transação com a requisição para um dispositivo remoto através de uma rede; e receber a partir do dispositivo remoto, informação resultando a partir da operação de arquivo, em que o método compreende as seguintes etapas: uma aplicação gerando os dados faz uma chamada ou emite uma requisição para entregar a transação, e esta chamada ou requisição é passada para o gerenciador de transação; em que, em resposta, o gerenciador de transação gera uma notificação de preparo anterior; em que o redirecionador recebe a notificação de preparo anterior a partir do gerenciador de transação e, em resposta, atualiza os dados para o servidor via a rede, e em que o servidor passa os dados para um NTFS; em que um gerenciador de transação do servidor sinaliza ao redirecionador quando a operação de preparo anterior está completa; em que o redirecionador recebe uma notificação de preparo a partir do gerenciador de transação e envia uma mensagem de notificação de preparo para o servidor em resposta à notificação de preparo, a qual é passada para o gerenciador de transação do servidor, em que o gerenciador de transação do servidor passa a notificação de preparo para o NTFS; e em que a notificação de preparo causa que o cliente e o servidor armazenem os dados de um modo que permita aos dados serem entregues ou revertidos, em que os dados são então processados utilizando operações de entrega de duas fases.

10. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que determinar se um FCB existente pode ser utilizado para a requisição adicionalmente compreende determinar se o FCB existente está associado com uma transação neutra.

11. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que determinar se um FCB existente pode ser utilizado para a requisição adicionalmente compreende comparar um nome de caminho e o contexto de transação para a requisição com um nome de caminho associado com o FCB existente.

12. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que o método é executado em um modo núcleo.

13. Método, de acordo com a reivindicação 9, CARACTERIZADO adicionalmente por compreender indicar de forma seletiva na requisição que o dispositivo remoto deve sinalizar para a máquina local em resposta à uma operação de arquivo sendo executada no arquivo que foi requisitado por um dispositivo diferente do dispositivo local.

14. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que a transação é enviada com a requisição utilizando um protocolo baseado em um protocolo de bloco de mensagem do servidor (SMB).

15. Método, de acordo com a reivindicação 14, CARACTERIZADO pelo fato de que o protocolo suporta operações de arquivo remoto não transacionadas.