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

Description

Report of the Invention Patent for "SYSTEM TO SUPPORT TRANSACTED REMOTE FILE OPERATIONS BETWEEN A LOCAL DEVICE AND A REMOTE DEVICE AND METHOD FOR IMPLEMENTING A REMOTE FILE OPERATION TRANSACTED ON A LOCAL DEVICE".

TECHNICAL FIELD

[001] Several embodiments described below generally relate to network communication, and more particularly but not exclusively to methods and systems for allowing transacted file operations over a network.

BACKGROUND OF THE INVENTION

Transactions have long been provided by databases and transaction processing systems. Transactions provide a simplified failure model desirable for application programmers by grouping a series of operations into a single atomic operation, that is, a group of operations whose results of individual operations stand or fall together. If only one operation fails, the effects of all operations in the group, regardless of the number of operations associated with the transaction, are "undone" or reversed. This solidarity between operations is provided with respect to any number of failures and eventually the respective transaction processing system achieves one of two states whereby all operations were applied or none of the applications were applied. SUMMARY OF THE INVENTION

According to aspects of the various embodiments described, there is provided a method and system for transacting archive operations over a network. In one aspect, a computing platform (ie client) can remotely access a file on another computing platform (ie server) via the network. In this regard, each of the client and server includes a transaction manager (TM) and a file system (FS). The client also includes a redirector (RDR), while the server includes a server component (SRV).

[004] In operation, RDR receives a request for a remote transacted file operation. In response to the request, the RDR examines looks for the transaction from the request and has the transaction conducted for transmission to the server (for example, the TM in one mode). The RDR then sends the transaction information (for example, a driving bubble in one mode) to the server over the network. The SRV receives transaction information, which the server's TM and FS then use to perform the archive operation. The server then returns the result of the file operation to the client via the network.

[005] In another aspect, RDR allows more than one remote file operation transaction to be opened for a file. When RDR receives a new request for a transacted remote file operation, RDR determines if a "dirty" version of the remote file (that is, a recorded version) is known to the client. RDR then uses the dirty version for the new request instead of the original version of the file. In some embodiments, RDR only allows a single transactional write operation to be opened at the same time for a given file.

In yet another aspect, RDR determines whether a new request for a transacted remote archive operation can use archive information already known to the client. If the same file information can be used, RDR uses this same file information instead of storing another copy of the file information.

In yet another aspect, RDR may associate an opportunistic lock with transactions for a given remote file. In one embodiment, the lock does not prevent the local server from accessing the file, but causes the server to send a message to the client that the lock has been broken. RDR can then check whether a lock has been broken for a given file by determining whether a new request for a transacted remote file can use file information already cached on the client. BRIEF DESCRIPTION OF DRAWINGS

Non-limiting and non-exhaustive embodiments are described with reference to the following figures, where like reference numerals refer to like portions throughout the various views unless otherwise specified.

[009] FIG. 1 presents an example of a system capable of utilizing transacted remote archive operations;

FIG. 2 shows an example of components of a client of a system server of FIG. 1;

FIGS. 3 and 3A show illustrative processing streams for a remote file operation transacted between the client and server of FIG. 2;

FIG. 4 shows an example of various remote file accesses by the client and server of FIG. 2;

FIG. 5 shows an illustrative processing flow for performing a two-phase delivery of a transaction over a network;

FIG. 6 presents an example of components for implementing transaction management;

FIG. 7 shows an illustrative processing flow for core level transactions;

FIG. 8 shows an example of a security feature; and FIG. 9 depicts a general computer environment that can be used to implement techniques described herein according to various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Illustrative Network Environment As previously described, transactions have been used in transaction processing and database systems, but in the following embodiments transactions are used for remote file operations. FIG. 1 illustrates a system 100 in which a client may transact file operations on a client via a network 101. In the illustrative network environment of FIG. 1, several client computing devices 105, 110, 115, and 120, which may also be referred to as client devices, are coupled with at least one server device 125 via network 101. Network 101 is intended to represent any one of these. variety of conventional topologies and network types, which may include wired / wireless networks. Network 101 may further utilize any of a variety of conventional network protocols, including public and / or proprietary protocols. Network 101 may include, for example, the Internet as well as possibly at least parts of one or more local area networks (LANs), wide area networks (WANs), and so forth.

Client device 105 may include any of a variety of conventional computing devices, including, but not limited to, a desktop personal computer (PC), workstations, large computers, Internet devices, and Game consoles. Additional client devices associated with network 101 may include personal digital assistant (PDA) 110, laptop computer 115 and mobile phone 120, etc., which may be in communication with network 101 by a wired connection and / or wireless. Still further, one or more of client devices 105, 110, 115 and 120 may include the same device types, or alternatively different device types.

Server device 125 may provide any of a variety of data and / or functionality for computing devices 105, 110, 115, and 120. Data may be publicly available or alternatively restricted, for example restricted. only certain users or available only if an appropriate fee is paid, etc.

Server device 125 is at least one of a network server and an application server, or a combination of both. Server device 125 is any device that is the content source, and client devices 105, 110, 115, and 120 include any devices that receive such content. Therefore, in a nonhierarchical network, the device that is the source of the content is referred to as the server device and the device that receives the content is referred to as the client device. Both types of devices are capable of loading and running software programs, including operating systems and applications, in accordance with the illustrative embodiments described herein. Additionally, data and functionality may be shared between client devices 105, 110, 115 and 120. That is, service device 125 is not the sole source of data and / or functionality for respective client devices.

At data source 130 or 135, software programs, including operating systems and applications, are prepared and / or provided for either server device 125 or client devices 105, 110, 115 and 120 for execution. For the sake of consistency, the discussion hereinafter later refers to "applications" that encompass any of at least software programs, operating systems, and applications, either singularly or in combination, as known in the art. Additionally, applications are disseminated to server device 125 both offline as from data source 130 and online as from data source 135. Still further, applications are typically disseminated to client devices. 105, 110, 115 and 120 online from server device 125 or data source 135. Devices and methods for offline dissemination thereof are also known.

According to various embodiments described below, the dissemination of at least one of the data and functionality between devices 105, 110, 115, 120 and 125 may be implemented as a transaction. More particularly, a transaction is a group of operations that are performed synchronously or asynchronously as a single atomic operation, both within devices 105, 110, 115, 120, and 125 as in a network environment such as the example of FIG. 1. An example of the transacted remote file operations performed over the network is described in more detail below in conjunction with FIGs. 2 to 7.

Transacted remote file operation [0025] FIG. 2 illustrates components of two system devices 100 (e.g., selected from devices 105, 110, 115, 120, and 125) of FIG. 1 which are operating as a client 202 and a server 204 for the purposes of a transacted remote file operation. In this embodiment, both client 202 and server 204 use a version of the Microsoft® Windows® operating system. In other embodiments, different operating systems may be used.

In this embodiment, client 202 includes an application 212, an input / output (I / O) manager 214, a file system (FS) 216, a redirector selector 218, a transaction manager (TM) 222, and a redirector (RDR) 220. Server 204 in this embodiment includes a server (SRV) component 234, an I / O manager 214A, an FS 216A, and a TM 222A. In this embodiment, client 202 and server 204 can communicate with each other via network 100 (FIG. 1). In some embodiments, these components are implemented by software.

In this "Windows" mode, I / O managers 214 and 214A, FSs 216 and 216A are implemented by NT file system (NTFS) and redirector selector 218 is implemented by multiple UNC provider (MUP), where The UNC is an acrosemia for Uniform Naming Convention. Thus, the redirector selector 218 is also referred to herein as MUP 218. In addition, Microsoft® Windows® operating system RDR and SRV (with added functionality) implement RDR 220 and SVR 234, respectively. Illustrative additions to the Microsoft® Windows® operating system RDR and SVR are described below. Still further, in this embodiment, TM 222 and TM 222A are implemented as core level transaction managers in this illustrative embodiment and are described in more detail below. Other modalities may use different I / O managers, file systems, redirector selectors, TMs, and / or RDRs.

FIG. 3 illustrates an illustrative processing flow for a remote file operation transacted between client 202 and server 204 (FIG. 2). Referring to FIGs. 2 and 3, a transacted remote file operation is performed as follows according to one embodiment.

In block 302, RDR 220 receives a request for the file transaction transacted on a file residing on server 204. Typical file operations include creating a new file, reading a file, writing a file, copying a file, rename a file, etc. In this embodiment, the request for a transacted file operation is generated by application 212, which is a user-level application as shown in FIG. 2. The request uses a structure that includes a field for the transaction context. The request is received by the I / O manager 214, which determines whether the request is for a local file or for a remote file. In this mode, I / O manager 214 is a standard component of the Microsoft® Windows® operating system. For example, application 212 can make the request via a call to I / O manager 214 named UNC (which is in the form of Wserver \ share \ subdirectorv \ filenameV I / O manager 214 then passes the request to MUP 218. There may be multiple identifiers for one transaction and multiple transactions for a given file. for a file on the client, the I / O manager 214 would pass the request to NTFS 216 in the default mode, [0030] MUP 218 then finds the redirector needed to execute the request, in this case the redirector is RDR 220. MUP 218 is a standard component of the Microsoft® Windows® operating system.In this mode, RDR 220 is a version of the RDR of the Microsoft® Windows® operating system, with additions so that RDR can interact with TM 222 to perform transactions Additions include, for example, the ability to retrieve transaction contexts for transactional file operations from requests, assign file control blocks (FCBs) for transactional file operations, send transactions to remote devices. receive network responses to transactional file operations (including File identifiers and version identifiers), perform transaction operations under the direction of TM 222, and function as a resource manager with TM 222 so that RDR 220 can keep track of the status of a transaction. In some embodiments, RDR 220 is implemented as described in commonly-assigned US Patent Application No. 09 / 539,233, filed March 30, 2000, entitled "Transactional File System" and Application No. [Case No. MS-1]. 1781US]. Operating as a resource manager is described below. RDR 220 contains features for transaction buffering, cache memory, file control blocks (FCBs), file object extensions (FOBXs), and other structures required to process the transaction and request.

In block 304, RDR 220 retrieves the transaction from TM 222 and conducts the transaction for transmission to server 204. In one embodiment, RDR 220 retrieves the transaction by calling an API (the modalities of which are described below). ) exposed by TM 222 and drive the transaction by formatting transaction information (e.g., a driving bubble) for transmission using a version of the SMB protocol that has been extended to support transactions. SMB extensions of an illustrative embodiment are summarized below in conjunction with Tables 1 through 3. In block 306, RDR 220 sends the transaction and requests to server 204, as indicated by an arrow 236. In block 308, RDR 220 receives results from the file operation from server 204. For example, server 204 sends a response to the request containing the file and version identifiers mentioned above. In this embodiment, SRV 234 is a version of SRV of the Microsoft® Windows® operating system, with additions so that SRV can interact with a client across a network to perform transactions using SMB extension, including passing File handles. and release to clients during transacted remote file operations. EXTENSION - DESCRIPTION Adds a new command: NT_TRANSACT_CREATE2 Takes a conducted transaction and sends two structures across the network: REQ_CREATE_WITH_EXTRA_OPTIONS and RESP_CREATE_W ITH_EXTRA_OPTIONS. These two structures are defined respectively in Tables 2 and 3 and are extensions of the SMB structures: REQ_CREATE_WITH_SD_OR_EA and RESP_EXTENDED_CREATE_WITH_SD_OR_EA.

Adds a new capacity bit: CAP_TXF CAPTXF is set or reset by the server to indicate if the server supports transactions. CAP_TXF is part of SMB Negotiate Response. In this mode, GAP_TXF is set to 0x20000 to indicate that the server supports transactions.

Adds a new identifier: S M B_F IN D_TR AN S ACTE D_0 P E R ATI N N for SMB FiND request, FIND request structure (REQ_FIND_FIRST2) is defined in Table 4 and the response structure in Table 5, SMB_FlND_TRANSACTED_OPERATION

[0032] Indicates that a transaction is being used. This identifier is used because in this mode, search operations are path based rather than identifier based. In this embodiment, this identifier is set to 0x20. Transaction information is sent at the end of the FIND and ECHO commands if this identifier is set.

[0033] Extends the ECHO command to send notifications of transaction state changes. The request / response structures are defined in Tables 6 and 7.

The SMB ECHO command is extended to provide notification of the previous staging, staging, delivery, and rollback states of a transaction operation from the server to the client. TABLE 1 REQ_CREATE_WITH_EXTRA_OPTIONS FIELD - CONTENT DESCRIPTION _ULONG (Indicators) NTCREATExxx Creation Identifiers _ULONG (RootDirectoryFid) Optional Relative Open Directory ACCESS_MASK DesiredAccess Desired Access (NT Format) LARGEJNTEGER AlIocationSize The initial file size Attributes Size of the ALONG file AlertsAt the length of the file ALONG file size (Share Access) Sharing access _ULONG (CreateDisposition) Action to take if file exists _ULONG (CreateOptions) Options for creating a new file _ULONG (SecurttyDescriptionLength) SD Size in bytes JJLONG (EaLength) Attribute Size extended (EA) in bytes JJLONG (NameLength) Name size in characters _ULONG (ImpersonationLevel) Quality of Service (QOS) security information JJCHAR SecurityFlags JJLONG (TransactionLength) security QOS information Size of transaction context driven in bytes JJLONG (EfsStreamLength) ) Size d encrypted file system ($ EFS) stream in bytes UCHAR Buffer [1] Buffer for the file name, which is aligned in data buffer with a DWORD limit (4 bytes) UCHAR Name [| The file name (not ending in NUL) TABLE 2 RES P_C RE ATE_W I TH_EXT R A_0 EN IO NS FIELD - CONTENT DESCRIPTION UCHAR OpIocKLevel The opportunistic lock level granted UCHAR - ExtendedResponse Set to 1 for Extended Response _USHORT (Fid) AID File Extension _ULONG (CreateAction) Action Taken _ULONG (EaErrorOffset) Error Offset EA TIME CreationTime The Time File Was Created TIME LastAcessTime The Time File Was Accessed TIME LastWriteTime The Time File Was Last Written TIME ChangeTime The time the file was last changed _ULONG (FileAttributes) The file attributes LARGEJNTEGER AlIocationSize The number of bytes allocated LARGE INTEGER EndOfFile The end of the file offset JJSHORT (FileType) The file type of the _USHORT (DeviceState) file ) IPC device state (for example, channel) BOOLEAN Directory TRUE if this structure is a UCHAR directory VolumeGuid [16] A GUID volume (Globally Unique ID) UCHAR Fileld [8] The _ULONG (MaxlmalAccessRights) file ID The access rights for the session owner JJLONG (GuestMaximalAccessRights) The maximum access rights for visitors LARGEJNTEGER FilesystemFid The NTSF Fid on the server, to differentiate between different files having the same path name, The same path name could refer to two different files while using transactions (TxF) JJLONG (VersionNum); 0 TxF version number of file that is open TABLE 3 REQ_FIND_FIRST2 FIELD - DESCRIPTION CONTENTS JJSHORT (SearchAttributes) Search Attributes _USHORT (SearchCount) Maximum number of records to return _USHORT (Indicators) Additional Information: bit set to 0 - close search after this request; 1 - close search if the end has been reached; 2 - returns Reset Keys _USHORT (Information Light) Information Level _ULONG (SearchStorageType) Search Storage Type UCHAR Buffer [1] File Name TABLE 4 Rsp_find_first2 FIELD - CONTENT DESCRIPTION _USHORT (Sid) Search Identifier _USHORT (SearchCount) Number of Entries Returned _USHORT (EndOfSearch) Was the last entry returned?

_USHORT (EaErrorOffset) Offset within EA list if error exists EA _U LONG (Sea rchSto rageT y pe) Search storage type _USHORT (LastNameOffset) Offset within data to last input filename if server needs to restart search; otherwise 0 TABLE 5 REQUEST FIELD - CONTENT DESCRIPTION UCHAR WordCount Parameter word count = 1 _USHORT (SearchCount) Number of records returned _USHORT (EndOfSearch) Was the last entry returned?

_USHORT (EaErrorOffset) Offset within EA list if there is an error EA _USHORT (LastNameOffset) Offset within the data to the file name of the last entry if the server needs it to restart the search; otherwise 0 TABLE 6 Rsp_echo FIELD - DESCRIPTION DQ CONTENT UCHAR WordCount Parameter word count = 1 _USHORT (SequenceNumber) Sequence number of this echo _USHORT (ByteCount) Data byte count; min = 4 UCHAR Buffer [1] Data echoed TABLE 7 [0035] FIG. 3A shows block 302 (FIG. 3) in more detail according to one embodiment. In block 312, RDR 220 retrieves the transaction context for the requested file operation. When opening a transacted remote file, RDR 220 determines if a transaction is already associated with the request. For example, in one embodiment, a transaction is associated with a request by linking it with a thread, but in other embodiments different methods may be used to associate a transaction with a request. In one embodiment, RDR 220 performs this unchecked operation to see if the request has a transaction identifier associated with it. If so, the request is merged with the existing transaction. If not, RDR 220 handles the request in standard mode for non-transacted requests.

[0036] RDR 220 then assigns an FCB to the request. As mentioned earlier, multiple transactions with multiple requests can open a given file. Thus, in a block 302 embodiment (FIG. 3), a block 314 is executed in which RDR 220 determines whether an existing FCB can be used for the request. In this mode, RDR 220 checks to see if the file (ie, path name) of the request and the transaction context associated with the thread making the request is associated with these from an existing FCB. For example, if two write operations of the same file were requested in the same transaction, while processing the second request, an FCB would already exist for the first request. Because both operations are write operations, the same FCB can be used for both.

If in block 314 RDR 220 determines that an FCB exists with the same transaction context and file (ie path name) and version, then in block 316 the existing FCB is used. for the request. In some embodiments, the RDR 220 will use FCB that has the latest version. For example, if a file read operation follows an uncommitted write operation of the same file, RDR 220 uses the version of the file currently being used by the write operation. This approach allows for the most efficient use of caching.

However, if in block 314 an existing FCB cannot be used for the request, in block 318 RDR creates a new FCB for the request. In an alternative embodiment, a new FCB is created for each request.

FIG. 4 illustrates an example of several neutral transaction requests to the same file. As shown in FIG. 4, an operation 401 corresponds to a request for a read operation of a file. That is, the file operation is for "open for reading". Operation 401 has an H1 identifier and a T1 transaction associated with it. The file version that is requested by RDR 220 (FIG. 2) is indicated as version A. Assuming this is the first neutral transaction for this file, version A is retrieved from server 204 (FIG. 2) and cached on client 202 (FIG. 2) [0040] At a later time, an operation 402 is requested in the same file. In this illustrative operation 402 there is also a read operation having an identifier H2 and a transaction T2. Because the transaction is different from that of operation 401, RDR 220 again retrieves version A of the file from server 204.

[0041] In this example, an operation 403 is then requested in the same file in the same transaction as operation 402. Thus, operation 403 has an identifier H3 and is joined with transaction T2. However, operation 403 is a write operation in this example and so RDR 220 locally remembers (for example, caches) a version B of the file. Version B is sometimes referred to as a "dirty version".

An operation 404 is then requested in the same file in the same transaction as operations 402 and 403. Thus operation 404 has an identifier H4 and is also joined with transaction T2. In this example, operation 404 is a read operation. In this embodiment, resulting from block 314 (FIG. 3A), RDR 220 will remember and possibly cache version B for operation 404.

[0043] An operation 405 is then requested on the same file in a different transaction. Thus, operation 405 has an identifier H5 and is associated with a new transaction T3. Because the transaction is different from previous operations, in one mode RDR 220 again retrieves version A of the file from server 204. In another mode, RDR 220 recognizes that version A is still the current version without querying. server 204 (FIG. 2) and uses "local" version A. For example, this alternative embodiment may use opportunistic locks to become aware of any newer versions of the file residing on server 204. That is, RDR 220 may associate an opportunistic lock with the file that does not prevent writes to the file on server 204, but causes server 204 to signal to RDR 220 that the lock has been broken. In such a case, the RDR 200 would then know that version A is no longer the current version. In yet another embodiment, RDR 220 may query server 204 to determine the current version of the file and then reuse an existing FCB that is associated with the current version.

Then, in a 406 operation, transaction T2 is committed. This has the effect of changing the version on server 204. This new version stored on server 204 is referred to as version C. As previously described, because RDR 220 functions as a resource manager during all remote transactions, RDR 220 learns that server 204 has a new version of the file.

An operation 407 is then requested in the same file in the same transaction as operation 401. Thus operation 407 has an identifier H6 and is joined with transaction T1. However, because RDR 220 is aware of the C version of the file on server 204, RDR 220 remembers and possibly caches version C for this operation. In some embodiments, RDR 220 retrieves version C from server 204.

Similarly, when an operation 408 is requested to the same file by the same transaction as operation 405, operation 408 has an identifier H7 and is joined with transaction T3. Again, because RDR 220 is aware of the C version of the file on server 204, RDR 220 remembers and possibly caches version C for this operation.

FIG. 5 illustrates how data cached from client 202 (FIG. 2) is updated to (i.e. durably stored on) server 204 (FIG. 2) according to one embodiment. Referring to FIGS. 2 and 5, client 202 updates data to server 204 as described below, according to one embodiment.

[0048] In block 502, the application generating the data makes a call or issues a request to deliver the transaction. This call or request is passed to TM 222. In response, TM 222 generates a previous Readiness Notification (described below in conjunction with the illustrative Transaction Manager).

In this embodiment, RDR 220 receives Prior Preparation Notification from TM 222, as presented in block 504. In response, RDR 220 updates data to SRV 234 via the network. SRV 234 in turn passes the data to NTFS 216A. These operations are represented by a block 506. In some embodiments, the TM 222A of server 204 indicates to RDR 220 when the Previous Prepare operation is complete. Block 504 and 506 help ensure that data from client 202 to be written to server 204 is present on server 204 before a Prepare operation (described below in conjunction with Illustrative Transaction Manager) is performed.

In block 508, RDR 220 receives a Ready Notification (described below in conjunction with Illustrative Transaction Manager) from TM 222. In one embodiment, RDR 220 sends a Ready Notification message to the server. 204 in response to the Readiness Notification, which is passed to TM 222A. In turn, TM 222A passes the Ready Notification to NTFS 216A. These operations are represented by blocks 510 and 512. The Readiness Notification causes client 202 and server 204 to store data in a manner that allows data to be delivered or rolled back. In some embodiments, the TM 222A of server 204 tells RDR 220 when the Prepare operation is complete. The data is then processed using standard two-phase delivery operations (for example, operations that cause the transaction to be delivered or canceled), as represented by a block 514.

Although transaction management is described above as being performed using separate TM components (ie TM 222 and 222A), in other embodiments the transaction management infrastructure may be integrated into the file system infrastructure. . Additionally, in such integrated embodiments, transaction messages (e.g., Pre-Prepare, Prepare, Delivery, Cancel, etc., as described below) flow with the archive messages on the transmission channel. illustrative transaction manager [0052] FIG. 6 illustrates components used in executing a transaction according to one embodiment. A group of operations that constitute a particular transaction are to collectively possess properties known, at least to those in the art, by the "ACID" acrosemia, which includes "atomicity", "consistency", "isolation" and "durability". More specifically, all data updates resulting from the respective operations of a transaction are permanent or none is permanent (atomicity); a transaction leaves the underlying data in a consistent state (consistency); The effects of a transaction update are not visible to other operations running concurrently until the overall transaction is made permanent (isolation); and after a result for the transaction has been determined, the result is guaranteed never to change (durability).

The core level transaction management example of FIG. 6 is directed to an example of a distributed transaction involving more than one device and retains the expected "ACID" characteristics of a transaction. Additionally, while the example of FIG. Referring to core objects, the example is by no means limited to transactions implemented by core objects. More specifically, the transactions described here may be implemented by different objects than core objects, or by a different type of transaction manager.

In FIG. 6, a transaction corresponding to client application 600 utilizes at least transaction manager 605 on a first device as well as client application 600B and transaction manager 635 on a second device. Client application 600B is associated with client application 600. Transaction managers 605 and 635, which are in communication with each other, can be aggregates of core objects that maintain state information about transactions and general resources and additionally coordinate. the interaction or protocol between client applications and associated resource managers (RM).

Resource managers including RM 625 and RM 630 in the example of FIG. 6, maintains the state of at least one underlying resource that is capable of storing data in a durable state.

Non-exclusive examples of such features include databases and message queues. In a first device in the illustrative embodiment of FIG. 6, RM 625 corresponds to resource 627; RM 630 corresponds to resource 632; and on a second device, RM 655 corresponds to resource 657.

As shown in FIG. 6, transaction manager 605 on a first device includes the following core objects: transaction object (TX) 610, resource manager object (RMO) 615 and enlistment object (EN) 620; and transaction manager 635 on a second device includes the following core objects: TX 640, RMO 645, and EN 650. TX represents a particular transaction and can be opened by a process participating in the transaction.

[0057] The RMO represents a resource that participates in a particular transaction. Participation by the RMO in a transaction includes receiving two-phase delivery messages. Additionally, the RMO is persistent so that the corresponding transaction manager knows which transaction result is to be transmitted to a corresponding RM. Alternatively, the RMO can be transient thus allowing client applications to adhere to a transaction notification flow without managing a persistent RMO through failures.

[0058] EN represents the relationship between a transaction and a resource manager. A resource manager indicates that it will participate in a transaction by creating an enlistment in it. When the RMO has been required to perform an operation (such as Prepare, Deliver, etc.) on a particular transaction, it uses the EN to indicate participation. A resource manager may have more than one EN in a particular Transaction.

The two-phase delivery protocol, which is implemented to ensure that a transaction successfully updates all appropriate files, is described for a core environment with reference to the examples in FIGS. 6 and 7 as follows. In particular, after client application 600 opens core objects corresponding to transaction manager 605 on a first device and SRV 234 (FIG. 2) opens core objects corresponding to transaction manager 635 on a second device, a "staging" phase "705 begins with 705 being sent to each RM in the transaction a" prepare "order from a corresponding transaction manager. Thus warned, the RM prepares 710 by synthesizing resource data into a durable state so that data in the respective resources is capable of being "delivered" or "rolled back". Upon preparation, the RM transmits a confirmation message 715 to the corresponding transaction manager TX.

The "delivery" phase 720 is performed upon a transaction resolution whereby the transaction manager TX transmits a 725 "delivered" or "cancel / reverse" transaction result for each associated RM . RM then writes the result to an associated event log and the underlying resource data is delivered or rolled back according to the result of the transaction. Alternative modalities may allow volatile lists for which data for the transaction is not durable and therefore data is not recorded or retrieved.

Core level transaction management can be implemented by using application program interfaces (APIs) that are applicable to system architectures including, but not limited to, the Microsoft® Win32® application programming interface and operating system. Microsoft® Windows®. The APIs described here are exposed via an identifier-based interface, an "identifier" referencing the intended object of the API. In addition, unless asynchronous operation is explicitly required, operations on the respective core objects, particularly TX and RMO, are synchronous. Still further, operations corresponding to different modalities of a transaction may be implemented by various combinations of one or more of the APIs described herein. That is, some embodiments may utilize all of the APIs described herein, while other embodiments may utilize various combinations thereof.

APIs for implementing TX core object operations and a corresponding description of API functionality are provided below (more detailed descriptions of the associated routines are also provided below): PreprepareEnlistment: Also known as "Phase 0" processing, requests that TX transmits a previous staging message to all associated RMs; • PrepareEnlistment: Requests TX to transmit a prepare request to all included RMs. • CreateTransaction: opens a new TX; • OpenTransaction: opens an existing TX; • CommitTransaction: requests that TX be delivered; • RolIbackTransaction: Require TX to cancel or reverse the transaction. • SavePointTransaction: Require TX to save the transaction state; • GetTransactionlnfo: retrieves information about TX; and • SetTransactionlnfo: establishes TX information.

The APIs used to implement operations on RMO core objects and a corresponding description of API functionality are provided below (more detailed descriptions of the associated routines are also provided below): CreateResourceManager: creates a new RMO that represents a resource;

OpenResourceManager: Opens an existing RMO; DestroyResourceManager: Destroys the RMO, thus synthesizing it non-persistently;

GetResourceManagerlnfo: Retrieves information about the RMO;

SetResourceManagerlnfo: Set information about the RMO;

CreateEnlistment: Causes RMO to join a transaction and retrieve related notifications; and GetNotificationResourceManager: queries and returns an available RM notification.

APIs used to implement operations on TX core objects by an RMO core object after joining a transaction and a corresponding description of API functionality are provided below (more detailed descriptions of the associated routines are also provided below): PrePrepareComplete: Indicates that RM has completed the previous preparation as requested by a corresponding transaction manager. • PrepareComplete: Indicates that RM has completed preparing a transaction as requested by the corresponding transaction manager; • RolIbackComplete: Indicates that RM has completed the rollback of transaction work performed as requested by the corresponding transaction manager; and • CommitComplete: Indicates that RM has completed the delivery of transaction work as requested by the corresponding transaction manager.

Unfortunately, the APIs associated with TX, RMO, and núcleo core objects used to implement transaction management can expose one or more of the core objects to multiple security attacks. For example, a malicious or invalid RM could be included in a transaction to cause denial of service attacks by never responding to function calls or, alternatively, forcing transaction cancellations. Therefore, an additional illustrative example, also referring to FIG. 6, is directed to a secure, core-level distributed transaction.

The illustrative embodiment of FIG. 6 further provides a security solution for vulnerable core objects by applying a security descriptor, which may include an access control list (ACL), for at least one of their respective core objects.

In a first device, ACL 660 is applied next to TX 610, ACL 665 is applied next to RMO 615 and ACL 670 is applied next to EN 620. In a second device, ACL 675 is applied to TX 640, ACL 680 is applied to RMO 645 and ACL 685 is applied to EN 650.

[0068] An ACL defines the "rights" that a particular user or group of users are allowed or denied to exercise on a particular object. More specifically, as shown in illustrative ACL 810 of FIG. 8, an ACL that is applied to or bound with a core object includes at least the access control entry (ACE) comprising a corresponding security identifier (SID) and a corresponding set of rights. The ACE entries 1 through 12 in FIG. 8 include, respectively, corresponding SIDs 1 to 12 and corresponding RIGHTs 1 to 12.

[0069] SIDs 1 through 12 identify a user or user group that may attempt to implement an operation, or series of operations, on the core object to which the ACL is applied. RIGHTs 1 through 12 specify an operation or series of operations capable of being performed on the respective core object by the user or user group identified by the SID and further specify the accessibility of such operation or operations to the identified user or user group. That is, RIGHTs 1 through 12 may indicate that the identified user or user group is allowed to perform a specified operation or that the identified user or user group is prohibited from performing a specified operation.

The following is a list of illustrative operations that can be specified by RIGHTs 1 through 12 on an TX-applied ACL, followed by a description of the operation's functionality. RIGHTs 1 through 12 additionally specify that the operation is allowed or denied in TX for the user or user group identified by the corresponding SID. • TRANSACTION_QUERY_INFORMATION: for TX information; • TRANSACTION_SET_INFORMATION: to establish TX information; • TRANSACTION_ENLIST: to include in TX in the transaction; • TRANSACTION_COMMIT: to synthesize all data updates associated with durable TX; • TRANSACTION_ROLLBACK: to cancel, ie reverse the operation on TX; • TRANSACTION PROPOGATE: to transmit data from TX to another object; • TRANSACTION SAVEPOINT: to save the current transaction point; and • TRANSACTION MARSHAL: to transmit data regarding the transaction to another device.

The following is a list of illustrative operations that can be specified by RIGHTs 1 through 12 in an ACL applied to the RMO, followed by a description of the functionality of the operation. RIGHTs 1 through 2 additionally specify that the operation is allowed or denied in the RMO for the user or user group identified by the corresponding SID. • RESOURCEMANAGER_QUERY_INFORMATION: for information about the RMO; • RESOURCEMANAGER_SET_INFORMATION: to establish information about the RMO; • RESOURCEMANAGER_RECOVER: to determine the state of a transaction at the time of transaction failure; • RESOURCEMANAGER_ENLIST: to include the RMO in a transaction; • RESOURCEMANAGER_GET_NOTIFICATION: to receive notification upon transaction resolution from the transaction manager; • RESOURCEMANAGER_REGISTER_PROTOCOL: to register a protocol that RMO supports in the transaction; and • RESOURCEMANAGER_COMPLETE_PROPOGATION: to establish the appeal according to the resolution of the transaction;

The following is a list of illustrative operations that can be specified by RIGHTs 1 through 12 in an ACL applied to the EN, followed by a description of the functionality of the operation. RIGHTs 1 through 12 further specify that the operation is allowed or denied in EN for the user or user group identified by the corresponding SID. • ENLISTMENT_QUERY_INFORMATION: for information about EN; • ENLISTMENT_SET_INFORMATION: to establish information about EN; • ENLISTMENT_RECOVER: To determine the state of inclusion at the time of transaction failure. • ENLISTMENT_REFERENCE: to get and reference (or unselect) an include key; • ENLISTMENT_SUBORDINATE_RIGHTS: to roll back the transaction and to respond to notifications; and • ENLISTMENT_SUPERIOR_RIGHTS: to perform operations that a higher transaction manager would perform; such as initiating a previous prepare, prepare, or reverse rollback operation on a transaction.

Accordingly, each of the TX, RMO and EN core objects may have an ACL respectively applied to it. Thus, when an API attempts to initiate an operation on a respective core object, the ACL must be respected in determining whether the operation is allowed or denied to the user or user group from which the API originates.

More specifically, when an identifier is opened to perform an operation, a user or user group matching the API is checked along with the SID in the ACL; a list of allowed operations is generated; and the operation specified by the API is checked for operations allowed for the SID on a given identifier.

Alternative ways to ensure transaction management between core objects and enforce security parameters include applying security descriptors to core objects that can participate in a transaction according to the security model for the Microsoft® operating system. Windows®.

As reported above, APIs are exposed as an identifier-based interface, which is used to implement the security model. The following includes a more detailed description of the APIs, listed above, for implementing operations on TX core objects. Descriptions include a description of the routine, its corresponding arguments, and return values PreprepareEnlistment (INPHANDLETransactionHandle; INPHANDLEResourceManagerHandle).

This routine requires a Transaction to be "pre-prepared" by issuing a Pre-Prepare request to all associated RMs. Pre-Staging gives an RM with caching properties an opportunity to update its buffer memories, possibly to other RMs, before the Transaction enters the Staged state, in which downstream RMs can no longer accept changes.

If this routine is not called and a participating transaction has requested PhaseO processing, Previous Staging requests are issued as requested when a Staging is received. However, some configurations that include caching type RMs may cause unnecessary transaction rollbacks in distributed scenarios if there is no PreprepareEnlistment.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction to be prepared earlier;

ResourceManagerHandle: Provides an identifier for the Superior / TM-CRM that is previously preparing the transaction. Only this Superior-TM / CRM will be able to call PrepareEnlis-tment, SuperiorCommitTransaction, and SuperiorRollbackTransaction on this transaction.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUSJNSUFFICIENTRESOURCES

ST ATUS_TM_T 00_LATE

PrepareEnlistment (INPHANDLETransactionHandle, INPHANDLEResourceManagerHandle);

This routine requires a Transaction to be "prepared" by issuing a Prepare request to all its associated ResourceMa-nagers. This request begins with the two-phase delivery protocol.

[0080] A transaction participant issuing PrepareEnlistment synthesizes the transaction object in a durable state that will survive system or application failures; Such a participant performs recovery in the transaction after any type of failure in order to distribute a result. Failure to fulfill this requirement may result in resource loss as well as inconsistent transaction results.

Arguments: TransactionHandle: Provides an identifier for the Transaction to be prepared; e ResourceManagerHandle: Provides an identifier for a TM that is preparing the transaction. If the transaction was previously prepared (via a PreprepareEnlistment call), then ResourceManagerHandle associates with the Superior-TM / CRM that was used in the PreprepareEnlistment call. Additionally, only Superior-TM / CRM calling this API will be allowed to call SuperiorCommitTransaction and SuperiorRollbackTransaction in this transaction.

Return Value: 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 LPVOlD.

[0081] This routine creates a new Transaction object and returns an identifier for the new object.

Alternatively (if the ResourceManage-rHandle parameter is specified), this routine performs a "Join" operation on Transaction after it is successfully created.

Clients close the transaction identifier using the CloseHandle API. If the last transaction identifier closes without anyone calling CommitTransaction on the transaction, then the transaction is implicitly rolled back.

Arguments: TransactionHandle: Provides a pointer to the location that will receive a handle to the new Transaction;

DesiredAccess: Provides the mask specifying the desired access level.

Valid access mask choices are: SYNCHRONIZEPYou can perform synchronization operations on this handle TRANSACTION COMMITYou can use this handle to deliver the transaction TRANSACTION PREPAREYou can use this handle to cancel the transaction TRANSACTION SAVEPOINTPYou can use this handle to create savepoints for transaction TRANSACTION JOINYou can use this identifier to join this transaction as an RM TRANSACTIONREADATTRIBUTESPode read attributes associated with transaction TRANSACTION WRITE ATTRIBUTESPode write attributes associated with the transaction;

ObjectAttributes: Provides a pointer to an optional object attribute structure;

CreateOptionProvides optional transaction indicators. Valid create indicator choices include: TRANSACTIONCREATEPRESUMEDNOTHINGCreates an "not assumed" transaction.

ResourceManagerHandle: Provides an identifier for ResourceManager that receives notifications about a specified transaction;

NotificationMask: Specifies the notifications this Re-sourceManager would like to receive regarding this Transaction; e TransactionKey: Specifies an opaque pointer value that RM would like to receive along with any modifications to this Transaction. RM can use this to associate notifications with some object in the RM address space, thus preventing the need to perform a search each time a notification occurs.

Return Value: 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] This routine looks for an existing Transaction object and returns an identifier for Transaction. The caller specifies a string representation of a GUID in an ObjectName field of ObjectAttributes.

Alternatively (if the ResourceManage-rHandle parameter is specified), this routine also performs a "Join" operation on Transaction after it is opened.

Clients close the transaction identifier using a CloseHandle API. If the last transaction identifier closes without anyone calling CommitTransaction on the transaction, then the transaction is implicitly rolled back.

Arguments: TransactionHandle: Provides a pointer to the location that will receive a handle to Transaction if the open operation is successful;

DesiredAccess: Provides the mask specifying the desired level of access;

ObjectAttributes: Provides a pointer to an optional object attribute structure;

ResourceManagerHandle: Provides an identifier for Resource-Manager that receives notifications about the specified Transaction; NotificationMask: Specifies the notifications this ResourceMana-ger can receive regarding this Transaction; e TransactionKey: Optionally specifies an opaque pointer value that RM would like to receive along with any modifications to this Transaction. RM can use this to associate notifications with some object in the RM address space, thus preventing the need to perform a search each time a notification occurs.

Return Value: 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);

This routine requires that the Transaction associated with the TransactionHandle be delivered. Any transaction identifier that has been opened or created can be delivered with the desired Transaction_Commit access. As long as there is no restriction stating that only the creator of a transaction is allowed to deliver it.

[0088] If the Transaction in question has not previously issued a PrepareEnlistment request, then a two-phase delivery protocol may be started on all included RMs. This call can be viewed as a single phase delivery request being issued by the customer.

[0089] This routing is not called if Transaction was previously prepared via PrepareEnlistment. Only an RM that called PrepareEnlistment can resolve the transaction state using SuperiorCommitTransaction.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction to be delivered; e CommitOptions: The Transaction COMMIT RETAINING will be delivered. Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TRANSACTION_ABORTED

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

This routine requires that the Transaction associated with Transactio-nHandle be reversed. Rollback can be a partial rollback if the optional SavePoint is specified and is a valid savepoint. A SavePoint NULL argument indicates that Transaction must be completely reversed or canceled. An optional Roll-backReason structure can be provided; it will be retained in the Transaction object and can be retrieved by interested transaction participants via a call to GetlnformationTransaction. Arguments: TransactionHandle: Provides a handle indicating that the Transaction is reversed;

SavePoint: Provides a SavePoint name indicating how far a state of a transaction should be rolled back; and RolIbackReason: Provides a Reason for Rollback Return Values: 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] This routine requires that a "savepoint" be generated for a Transaction associated with TransactionHandle; This save point is used as a target for subsequent rollback requests.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction for which a SavePoint should be established;

SavepointFlags: Optionally provides a set of indicators that affect savepoint generation; e SavePoint: Provides a pointer to a location where a Savepoint identifier is stored.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TRANSACTION_COMMITTED

STATUS_TM_TRANSACTION_ABORTED

Query Information Transaction (INHANDLETransactionHandle, INTRANSACTIONINFORMATIONCLASSTransactionlnformationClass, OUT PVOlDTransactionlnformation, IN ULONGTransactionlnformationLength, OUTPULONGReturnLength Optional);

This routine returns requested information about the Transaction object represented by TransactionHandle.

Arguments: TransactionHandle: Provides an identifier indicating a Transaction for which information is being requested;

TransactionlnformationClass: Indicates which class of information about the Transaction object is being requested;

TransactionInformation: Provides a pointer to a buffer where the requested transaction information is stored;

TransactionlnformationLength: Indicates the size of buffer pointed to by Transactionlnformation; e ReturnLength: Provides a pointer to the location that will receive the size of the information written to the Transactionlnformation buffer.

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

This routine establishes the requested information about the Transaction object represented by TransactionHandle.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction whose information will be modified;

TransactionlnformationClass: Indicates which class of information about the Transaction object is being requested;

Transactionlnformation: Provides a pointer to a buffer where the requested transaction information is stored;

TransactionlnformationLength: Indicates a buffer size pointed to by Transactionlnformation; e ReturnLength: Provides a pointer to a location that will receive the size of the information written next to the Transaction Information buffer.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUSJNSUFFICIENTRESOURCES

STATUS_INVALID_INFO_CLASS

STATUS_INFO_LENGTH_MISMATCH

The following includes a more detailed description of the APIs listed above for implementing operations on RMO core objects. Descriptions include a description of the routine, the corresponding arguments, and the return values.

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

[0094] This routine creates a new ResourceManager object to represent a resource.

[0095] A ResourceManager object also serves as an endpoint for TM notifications regarding the Transactions that RM has joined; an RM requests these notifications by calling GetNotification- ResourceManager.

[0096] A ResourceManager is usually a persistent object, that is, the object must be reopened and recovery performed after each failure (system or RM). A transient version of a ResourceManager object can be created by specifying the RESOURCEMANAGER_NO_RECOVERY option. A transient RM is not required or allowed to perform recovery. The nonrecoverable RM option allows an application or RM to receive notifications about transaction progress (for example, PREPREPARE, PREPARE, COMMIT) without being required to implement all the complexity of recording staging and performing recovery.

Arguments: ResourceManagerHandle: Provides a pointer to the location that will receive a handle to the new ResourceManager;

DesiredAccess: Provides a mask specifying a desired access level. Valid access mask choices are: SYNCHRONIZE: To synchronize operations on an identifier, RESOURCE MANAGER_DESTROY: To destroy this resource manager, RESOURCE_MANAGER_READ_ATTRIBUTES: To read attributes associated with a resource manager, RESOURCE MANAGER_WRITE_ATTRIBUTES to write attributes with associated manager resource;

ObjectAttributes: Specifies the attributes for the new RM object; This includes the name of the RM;

CreateOptions: Specifies options for the created object; RESOURCEMANAGER_NO_RECOVERY: The ResouceManager object is not persistent and does not perform recovery; RESOURCEMANAGER COMMUNICATION: Resource-Manager knows how to communicate with other computers. Re-sourceManager can be used to conduct or hold transactions; RESOURCEMANAGER_CLUSTER_RECOVERY: Re-sourceManager knows how to read / distribute results to log files that may have failed through the other nodes in the cluster. ResourceManager can be used to retrieve transactions in a cluster; e NotificationRoutine: Specifies a notification routine to call when notifications are available for this ResourceManager.

Return Value: 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] This routine opens an existing ResourceManager object by name. If a target ResourceManager object is persistent but not currently open, the object is initially in a "retrieve" state and must be retrieved; After the recovery is complete, RecoveryCompleteResourceManager should be called. Arguments: ResourceManagerHandle: Provides a pointer to the location that will receive a handle to the existing ResourceManager object;

DesiredAccess: Provides the mask specifying the desired access to this object;

ObjectAttributes: Specifies the attributes for the new RM object;

OpenOptions: Specifies options for the object. Valid options include: RESOURCE_MANAGER_DETAILED_RECOVERY_NOTIFICATIONS

The resource manager receives detailed recovery notifications (with additional information about communication endpoints) instead of normal recovery notifications; and [0099] NotificationRoutine: Specifies a notification routine that will be called when notifications are available for this ResourceManager.

Return Value: 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] This routine destroys a ResourceManager object, causing it to be no longer persistent.

Arguments: ResourceManagerHandle: Provides an identifier indicating the ResourceManager object to be destroyed.

Return Value: STATUS_SUCCESS

STATUSACCESSDENIED

STATUSJNVALIDHANDLE

STATUSINSUFFICIENTRESOURCES STATUS_TM_NEEDS_RECOVERY.

QuerylnformationResourceManager (IN HANDLE ResourceManagerHandle, INRESOURCEMANAGERINFORMATIONCLASS

ResourceManagerlnformationClass, OUT PVOlDResourceManagerlnformation, INULONG

ResourceManagerlnformationLength, OUTPULONG ReturnLengthOptional).

[00101] This routine returns the requested RMO information represented by ResourceManagerHandle.

Arguments: ResourceManagerHandle: Provides an identifier indicating the ResourceManager for which information is being requested;

ResourceManagerlnformationClass: Indicates which class of information about the ResourceManager object is being requested;

ResourceManagerlnformation: Provides a pointer to a buffer where the requested ResourceManager information will be stored;

ResourceManagerlnformationLength: Indicates the size of buffer memory pointed to by ResourceManagerlnformation; e ReturnLength: Provides a pointer to the location to receive a size of the information written to the ResourceManagerlnformation buffer.

Return Value: STATUS_SUCCESS

STATUSACCESSDENIED

STATUSJNVALIDHANDLE

STATUSINSUFFICIENTRESOURCES

STATUSINVALIDINFOCLASS

STATUS_INFO_LENGTH_MISMATCH

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

This routine establishes the requested information about the RMO represented by ResourceManagerHandle.

Arguments: ResourceManagerHandle: Provides an identifier indicating the ResourceManager for which the information is being modified;

ResourceManagerlnformationClass: Indicates which class of information about the ResourceManager object is being requested;

ResourceManagerlnformation: Provides a pointer to a buffer where the requested ResourceManager information is stored; e ResourceManagerlnformationLength: Indicates the size of buffer memory pointed to by ResourceManagerlnformation; Return Value: 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] This routine causes the RMO to "join" a particular transaction and receive notifications relating to it.

[00104] The CreateEnlistment call does not change, and an RM can call this routine multiple times to change its Notification-Mask or TransactionKey. Subsequent calls to CreateEnlistment override a notification mask and transaction key without creating a new inclusion in the transaction.

[00105] NotificationMask can be used to request notifications to be received multiple times. For example, an RM receiving a PREPREPARE notification may request another by calling JoinTransaction and specifying the PREPREPARE indicator. Thus, an RM can receive multiple PREPREPARE requests. Such requests may be refused, which may be desirable if the transaction has continued past the point at which the requested notification would have been received. For example, requesting a PREPREPARE when any RM has already been notified to PREPARE may not be allowed.

Arguments: ResourceManagerHandle: Provides an identifier for an RM to receive notifications about the specified Transaction;

TransactionHandle: Provides an identifier for the Transaction with which RM wants to join;

NotificationMask: Specifies the notifications RM would like to receive regarding this Transaction. Valid masks are as follows and can be joined with an OR operator: TRANSACTION_NOTIFY_MASK_RM: Common notifications desired by an RM (PREPARE, COMMIT, ROLLBACK, SAVEPOINT), TRANSACTION_NOTIFY_MASK_CRM: Common notifications desired by a CRM or Superior TM (PrePrepare_Complete, CommitComplete .Complete. , RolIbackComplete, Saveback-complete), TRANSACTION_NOTIFY_PREPREPARE: Notification for PrePrepare, TRANSACTION_NOTIFY_PREPARE: Notification to PREPARE, TRANSACTION_NOTIFY_COMMIT: Notification to COMMIT, TRANSACTION_NOTIFY_ROLLBACK: Notification to ROLLBACK, TRANSACTION_NOTIFY_PREPREPARE_COMPLETE: Notification that PREPREPARE is complete, TRANSACTION_NOTIFY_PREPARE_COMPLETE: that PREPARE notification is complete, TRANSACTION_NOTIFY_COMMIT_COMPLETE: Notification that COMMIT is complete, TRANSACTION_NOTIFY_ROLLBACK_COMPLETE: Notification that ROLLBACK is complete, and TRANSACTION_NOTIFY_SAVEPOINT_COMPLETE: Notification that SAVEP OINT is complete; e TransactionKey: Specifies an opaque pointer value that RM would like to receive along with any notifications for this Transaction. RM can use this to associate notifications with some object in the RM address space, thus preventing the need to perform a search each time a notification occurs. Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_PARAMETER

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES STATUS_TM_TOO_LATE.

GetNotificationResourceManager (INPHANDLEResourceManagerHandle, INPTRANSACTION_NOTIFICATIONTransactionNotification, INPLARGEJNTEGERTimeout Optional);

This routine queries and returns an RM notification, if any is available.

Arguments: ResourceManagerHandle: Provides an identifier indicating the ResourceManager to which a notification should be returned;

TransactionNotification: Provides a pointer to a TRANSACTIONNOTIFICATION structure to be populated with the first available notification; e Timeout: Provides the time until which the caller wants to block while waiting for a notification to become available. If none are available when this timeout expires, the caller returns with STATUS_TIMEOUT.

Return Value: STATUS_SUCCESS

STATUS_TIMEOUT

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

The following includes a more detailed description of the APIs listed above for implementing operations on TX core objects by RMO core objects after joining with a transaction. Descriptions include a description of the routine, the corresponding arguments, and the return values.

PrePrepareComplete (INPHANDLEEnlistmentHandle);

[00108] This routine indicates that RM has completed the previous staging (also known as "PhaseO") processing of a Transaction as requested by KTM

Arguments: TransactionHandle: Provides an identifier indicating the Transaction for which the previous staging operation was completed.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

PrepareComplete (INPHANDLEEnlistmentHandle);

[00109] This routine indicates that RM has completed the preparation of a Transaction as requested by KTM.

Arguments: TransactionHandle: Provides a handle indicating the Transaction for which the prepare operation was completed.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

RolIbackComplete (INPHANDLEEnlistmentHandle);

[00110] This routine indicates that RM successfully completed the rollback of work performed by a Transaction as requested. If RM is unable to successfully reverse Transaction as requested, it must issue a request for a full rollback via RolIbackTransaction.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction for which the rollback operation was completed.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

CommitComplete (INPHANDLEEnlistmentHandle);

[00111] This routine indicates that RM has completed the delivery of work performed by a Transaction as requested.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction for which the delivery operation was completed.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

STATUS_TM_NOT_REQUESTED

In addition, propagation routines may be provided for core objects. Examples of these routines follow. RegisterProtocolAddressInformation (IN HANDLEResourceManager, IN PROTOCOLJDProtocolld, IN ULONGProtocolInformationSize, IN PVOlDProtocolInformationOptional).

[00113] This routine registers a resource manager as a communications resource manager for a particular protocol. It also associates an information bubble with this protocol. Only one resource manager can register for a protocol on a given machine.

Arguments: ResourceManager: Provides an identifier for the resource manager we are registering: Protocolld: the GUID identifying the protocol; ProtocolInformationSize: The size of ProtocolInformation; ProtocolInformation: optional bubble to associate with this protocol;

Return Values STATUS_SUCCESS STATUSJNVALIDHANDLE MarshallT ransaction (INPHANDLETransactionHandle, INULONGNumberOfProtocol, IN PROT OCOLID Protocol Array, INULONGBufferLength, INPVOlDBuffer, OUTPULONG BufferUsedOptional).

[00114] This routine requires that a Transaction representation corresponding to TransactionHandle be serialized into a buffer.

Arguments: TransactionHandle: Provides an identifier indicating the Transaction for which the delivery operation was completed;

NumberOfProtocois: Indicates the size of the protocol array;

ProtocolArray: A vector of PROTOCOL IDs (GUIDs) that specify the protocols that can be used to conduct this transaction. The vector must be sorted by preference - the first protocol in the vector is the preferred protocol, the second protocol is the second most preferred protocol, etc .;

BufferLength: Provides the size of Buffer Memory that is available;

Buffer: Provides a pointer to a buffer where transaction serialization should be stored; e BufferUsed: Provides a pointer to a location where the actual bytes written to buffer should be stored.

Return Values: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

GetProtocolAddressInformation (INULONGAddressBufferSize, OUTPVOlDAddressBuffer, OUTPULONGAddressBufferUsedOptional).

[00115] This routine requires that information representing all protocols registered on the machine be serialized in AddressBuffer. This information can then be passed to another machine and used as an argument to PushTransaction to extend a transaction to the machine on which Addresslnformation was generated. Arguments: AddressBufferSize: Provides the size of buffer that is available.

AddressBuffer: Provides the size of buffer that is available.

AddressBufferUsed: Provides a pointer to a buffer location where transaction serialization is stored.

Return Value: 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] This routine requires that the transaction represented by serialization in buffer be made available by the transaction manager. An identifier for the new Transaction object is returned after the transaction has been successfully propagated by one of the registered resource managers.

Arguments: TransactionHandle: Provides a pointer to where the handle representing the new Transaction should be stored;

NumberOfProtocolos: Indicates the size of the protocol vector;

ProtocolArray: A vector of PROTOCOL IDs (GUIDs) that specify the protocols that can be used to conduct this transaction. The vector must be sorted by preference - the first protocol in the series is the preferred protocol, the second protocol is the second most preferred protocol, etc .;

BufferLength: Provides the size of buffer that is available;

Buffer: Provides a pointer to a buffer where transaction serialization is stored.

Return Values: 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, OUTPULONGUponPulseUpOptionOUpOptionOulPulseUpOptional

[00117] This routine requests that the transaction be propagated to the destination machine using extension style propagation. Protocols will be used in the order in which they are listed in the ProtocolArray until one is successful. If no protocol succeeds in propagating to the destination machine, the routine returns failure.

Arguments: TransactionHandle: Provides a pointer to the transaction object that must be propagated to the remote machine;

Desti nation I nfoLength: Provides the size of Desti nation In-foLength that is available;

Destinationlnfo: Provides a pointer to a buffer where "endpoint" information for the destination is stored. This may be the output received from a call to GetProtocalAddressInformation on the destination machine;

ResponseBufferLength: Provides the size of the Response Buffer that is available;

ResponseBuffer: Provides a pointer to a buffer where transaction serialization is stored; e PushCookie: Provides a pointer to a buffer whose cookie representing this extension request will be stored.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

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

[00118] This call is used to retrieve the output of a PushTransaction call in the event that the initial PushTransaction call received a return code STATUS_BUFFER_TOO_SMALL. In this event, the caller is to call GetPushTransactionBuffer and passes a sufficient buffer size.

Arguments: TransactionHandle: Provides a pointer to the location where the handle representing the new Transaction is to be stored;

BufferLength: Provides the size of buffer that is available; e Buffer: Provides a pointer to a buffer where transaction serialization is stored.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

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

[00119] This routine is called by a CRM after it has successfully completed the propagation of a transaction. Arguments: TransactionHandle: Provides a pointer to the location where the handle representing the new Transaction is to be stored;

RequestCookie: Provides the RequestCookie that was received in the original PROPAGATE notification argument to indicate which request was completed;

BufferLength: Provides the size of Buffer Memory that is available; e Buffer: Provides a pointer to a buffer where transaction serialization is stored.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE STATUS_INSUFFICIENT_RESOURCES.

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

A CRM uses this routine to indicate that it failed to propagate the transaction as requested;

Arguments: TransactionHandle: Provides a pointer to the location where the identifier representing the new transaction is to be stored;

BufferLength: Provides the size of buffer that is available; e Buffer: Provides a pointer to a buffer where transaction serialization is stored.

Return Value: STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUSJNVALIDHANDLE STATUSJNSUFFICIENTRESOURCES.

Illustrative Computing Environment [00120] FIG. 9 illustrates a general computer environment 900 which may be used to implement the techniques described herein. Computer environment 900 is only an example of a computing environment and is not intended to suggest any limitations on the scope of use or functionality of computer and network architectures. Nor should the computer environment 900 be construed as having any dependency or requirement relating to any or the combination of the components illustrated in the illustrative computer environment 900.

Computer environment 900 includes a general purpose computing device in the form of a computer 902. Computer components 902 may include, but are not limited to one or more processors or processing units 904, system memory. 906 and the 908 system bus that couples various system components including the 904 processor with 906 system memory.

The 908 system bus represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a local processor or bus using any one of a number. variety of bus architectures. By way of example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA bus (EISA), a local Electronic Components Standards Association bus. (VESA), a Peripheral Component Interconnect (PCI) bus also known as a Mezzanine bus, an PCI Express bus, a Universal Serial Bus (USB), a Secure Digital bus (SD), or an IEEE 1394, that is , FireWire bus.

Computer 902 may include a variety of computer readable media. Such media may be any available media accessible by the computer 902 and includes both volatile and non-volatile media as well as removable and non-removable media.

System memory 906 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 910; and / or nonvolatile memory, such as read-only memory (ROM) 912 or flash RAM. The Basic Input / Output System (BIOS) 914, which contains the basic routines that help transfer information between elements within the 902 computer, such as during startup, is stored in ROM 912 or flash RAM. RAM 910 typically contains data and / or program modules that are immediately accessible and / or presently operated by processing unit 904.

Computer 902 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example, FIG. 9 illustrates hard disk controller 916 for reading and writing to non-removable, nonvolatile magnetic media (not shown), magnetic disk controller 918 to reading and writing to non-volatile removable magnetic disk 920 ( for example, a "floppy disk") and an optical disk controller 922 for reading and / or writing to a removable, non-volatile optical disk 924 such as a CD-ROM, DVD-ROM, or other optical medium. Each of the 916 hard disk controller, 918 magnetic disk controller, and 922 optical disk controller is connected to the 908 system bus through one or more 925 media interfaces. Alternatively, the disk controller 916, the 918 magnetic disk controller and 922 optical disk controller can be connected to the system bus 908 through one or more interfaces (not shown).

Disk controllers and their associated computer readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for the 902 computer. Although the example illustrates a hard disk 916, removable magnetic disk 920 and removable optical disk 924, it is appreciated that other types of computer readable media that can store data that is accessible by a computer, such as magnetic cassettes or other magnetic storage devices, flash memory cards , CD-ROM, digital versatile discs (DVD) or other optical storage, random access memories (RAM), read-only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like can also be used to implement the illustrative computing system and environment.

Any number of program modules may be stored on hard disk 916, magnetic disk 920, optical disk 924, ROM 912 and / or RAM 910, including by way of example operating system 926, one or more. more application programs 928, other program modules 930 and program data 932. Each of such operating system 926, one or more application programs 928, other program modules 930 and program data 932 (or some combination thereof) may play the role of transactions, in accordance with the illustrative embodiments described above, to implement all or part of the resident components supporting the distributed file system.

[00128] A user can enter commands and information into computer 902 via input devices such as keyboard 934 and pointing device 936 (for example, a "mouse"). Other 938 input devices (not specifically shown) may include a microphone, joystick, gaming platform, satellite antenna, serial port, scanner and / or the like. These and other input devices are connected to the processing unit 904 via the input / output interfaces 940 that are coupled with the 908 system bus, but can be connected by other interface and bus structures such as a port. parallel port, game port, or a universal serial bus (USB).

The 942 monitor or other display device may also be connected to the 908 system bus via an interface such as the 944 video adapter. In addition to the 942 monitor, other peripheral output devices may include components such as speakers (not shown) and the 946 printer, which can be connected to the 902 computer via the 940 I / O interfaces.

Computer 902 can operate in a networked environment using logical connections to one or more remote computers, such as remote computing device 948. By way of example, remote computing device 948 can be a PC, portable computer , a server, a router, a network computer, an even device, or another common network node, and the like. Remote computing device 948 is illustrated as a portable computer which may include many or all of the elements and features described herein related to computer 902. Alternatively, computer 902 may also operate in a non-networked environment.

The logical connections between the 902 computer and the 948 remote computer are described as a 950 local area network (LAN) and a 952 wide area network (WAN). Such network environments are common in offices, home networks, and corporate computer, intranets and the Internet.

When deployed in a LAN network environment, computer 902 is connected to local network 950 via the network interface or adapter 954. When deployed in a WAN network environment, computer 902 typically includes modem 956 or other device for establishing communications over wide 952. The 956 modem, which may be internal or external to the 902 computer, may be connected to the 908 system bus via the 940 I / O interfaces or other appropriate mechanisms. The illustrated network connections are illustrative and another device for establishing at least one communication link between computers 902 and 948 may be employed.

In a networked environment, such as illustrated with computing environment 900, the described program modules relating to computer 902, or parts thereof, may be stored in a remote memory storage device. By way of example, remote application programs 958 reside on a memory device of remote computer 948. For illustration purposes, applications or programs and other executable program components, such as the operating system, are illustrated herein. as separate blocks, although it is recognized that such programs and components reside at various times in different storage components of computing device 902 and are executed by at least one computer data processor.

Various modules and techniques may be described herein within the general context of computer executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. to perform particular tasks or implement particular abstract data types. These program modules and the like can be executed as native code or can be downloaded and executed, such as in a virtual machine or other instant build execution environment. Typically, the functionality of program modules may be combined or distributed as desired in the various embodiments.

[00135] An implementation of these modules and techniques may be stored or transmitted via some form of computer readable medium. Computer readable media can be any available media that can be accessed by a computer. By way of example and not limitation, computer readable media may comprise "computer storage medium" and "media".

"Computer storage medium" includes volatile, non-volatile, removable, and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, or other data. . Computer storage includes, but is not limited to RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROMs, digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape. magnetic disk storage or other magnetic storage devices or any other means that may be used to store the desired information and which may be accessed by a computer.

The "communication medium" typically incorporates computer readable instructions, data structures, program modules, or other data into a modulated data signal, such as a carrier wave or other transport mechanism. The media also includes any means of distributing information. The term "modulated data signal" means a signal having one or more of its characteristics established or altered to encode the information in the signal. As a non-limiting example only, the media includes wired media such as a wired network or direct wired connection and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

Reference has been made throughout this specification to "a certain embodiment", "a embodiment" or "an illustrative embodiment" meaning that a particular aspect, structure or feature described is included in at least one embodiment of the present invention. Thus, the use of such phrases may refer to more than just one mode. Additionally, the described features, structures or characteristics may be suitably combined in one or more embodiments.

However, those skilled in the relevant art may recognize that the invention may be practiced without one or more of the specific details or with other methods, resources, materials, etc. In other examples, well-known structures, features or operations have not been presented or described in detail merely to avoid obscuring aspects of the invention.

While the illustrative embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and features described above. Various modifications, changes, and apparent variations to those skilled in the art may be made in the arrangement, operations, and details of the methods and systems of the present invention disclosed herein without departing from the scope of the claimed invention.

Claims (15)

1. System for supporting remote file operations transacted between a local device and a remote device, the system being characterized by comprising: a transaction manager; and a redirector to receive a request to perform a file operation on a file residing on the remote device, local and remote devices connected to a network, wherein the redirector is to send the request to the remote device over the network within a network. transaction; wherein the system comprises means for performing steps, wherein an application generating the data makes a call or issues a request to deliver the transaction, and that call or request is passed to the transaction manager; wherein, in response, the transaction manager generates a previous staging notification; wherein the redirector receives the previous staging notification from the transaction manager and, in response, updates the data to the server via the network, and wherein the server passes the data to an NTFS; wherein a server transaction manager signals the redirector when the previous prepare operation is complete; where the redirector receives a staging notification from the transaction manager and sends a staging notification message to the server in response to the staging notification, which is passed to the server transaction manager, where the staging manager server transaction passes staging notification to NTFS; and wherein the staging notification causes the client and server to store the data in a manner that allows the data to be delivered or rolled back, wherein the data is then processed using two-phase delivery operations. System according to claim 1, characterized by the fact that the transaction manager is not integrated into a file system. System according to claim 1, characterized in that the redirector is for determining whether an existing FCB that is associated with a neutral transaction can be used for the request. System according to claim 1, characterized in that the redirector, when determining whether an existing FCB can be used for the request, is to compare a request path name and transaction context with a request name. path associated with the existing FCB. System according to claim 1, characterized by the fact that the transaction manager is a core level transaction manager. System according to claim 1, characterized in that the redirector is to selectively indicate in the request that the remote device must signal to the local machine in response to a file operation being performed on the file that has not been requested by the redirector. System according to claim 1, characterized in that the redirector sends the transaction with the request using a protocol based on a server message block (SMB) protocol. System according to claim 7, characterized by the fact that the protocol supports non-transacted remote file operations. A method for implementing a transacted remote file operation on a local device, the method being characterized by: receiving a request for a transacted remote file operation comprising: retrieving a transaction; conduct the transaction; send the request transaction to a remote device over a network; and receiving from the remote device information resulting from the file operation, wherein the method comprises the following steps: an application generating the data makes a call or issues a request to deliver the transaction, and this call or request is passed to the transaction manager; wherein, in response, the transaction manager generates a previous staging notification; wherein the redirector receives the previous staging notification from the transaction manager and, in response, updates the data to the server via the network, and wherein the server passes the data to an NTFS; wherein a server transaction manager signals the redirector when the previous prepare operation is complete; where the redirector receives a staging notification from the transaction manager and sends a staging notification message to the server in response to the staging notification, which is passed to the server transaction manager, where the staging manager server transaction passes staging notification to NTFS; and wherein the staging notification causes the client and server to store the data in a manner that allows the data to be delivered or rolled back, wherein the data is then processed using two-phase delivery operations. A method according to claim 9, characterized in that determining whether an existing FCB may be used for the request further comprises determining whether the existing FCB is associated with a neutral transaction. A method according to claim 9, characterized in that determining whether an existing FCB can be used for the request further comprises comparing a path name and transaction context for the request with a path name associated with the request. Existing FCB. A method according to claim 9, characterized in that the method is performed in a core mode. A method according to claim 9, further characterized by comprising selectively indicating in the request that the remote device must signal to the local machine in response to a file operation being performed on the file that was requested by a device other than the device. local device. Method according to claim 9, characterized in that the transaction is sent with the request using a protocol based on a server message block (SMB) protocol. Method according to claim 14, characterized in that the protocol supports non-transacted remote file operations.