用于在数据库管理系统中为文件操作提供锁定的技术

技术领域

本发明涉及在数据库管理系统中执行文件操作。

背景技术

数据被存储在诸如数据库和文件服务器的各种类型的存储机 构中。每个存储机构都典型地具有其自己的访问方法。例如，SQL 协议一般用于对数据库执行操作，以及NFS协议一般用于对文件系 统执行操作。SQL协议是用于访问和处理存储在数据库中的数据的 ANSI标准。NFS协议是支持通过网络对文件执行文件操作的分布 式文件系统协议。NFS是用于在UNIX主机之间共享文件的已知标 准。在NFS协议中，使用文件句柄对文件执行文件系统操作，该文 件句柄是识别特定文件的标识符。在RFC 3010中指定的当前版本 (版本4)的NFS支持版本3以上的附加功能，例如，增强安全性 和有状态(stateful)操作的性能。

目前，数据库管理系统不支持使用NFS协议访问数据库。因此， 当用户想要访问数据时，用户必须确定哪种类型的存储机构正在存 储数据以确定访问数据的适当方式，例如，用户必须确定数据是否 被关联地存储在数据库或文件系统中。在许多情况下，用户确定数 据实际存储在哪个存储机构中将成为用户的负担。

此外，期望由于多种原因将尽可能多种类的数据存储在单个存 储机构中。使保存的不同种类的存储机构的数量最小化降低了需要 保存存储机构所需的资源量。此外，将多种数据存储在中央位置(例 如，数据库)中促进了使用的简易性和安全性，这是因为数据没有 被存储在多个分散的位置中。

因此，期望用于在数据库管理系统中执行文件系统操作的方 法。在这部分中描述的方法是可执行的方法，但不必须是预先设定 或执行的方法。因此，除非另外指出，否则不应假设在本部分中描 述的任何方法仅由于包括在本部分中而被限定为现有技术。

附图说明

通过附图中的实例示出了本发明的实施例，而并不用于限制本 发明，其中，相似的参考标号表示相似的元件，其中：

图1是根据本发明实施例的能够处理在有状态协议中实现的请 求的系统的高级视图的方框图；

图2是根据本发明实施例的数据库服务器的功能组件的方框 图；

图3是示出根据本发明实施例的处理文件操作的功能步骤的流 程图；

图4是示出根据本发明实施例的使用数据库锁和文件系统操作 锁的功能步骤的流程图；

图5是根据本发明实施例的存储基于模式的资源的在先版本信 息的方框图；

图6A和6B是根据本发明实施例的存储不基于模式的资源的 在先版本信息的方框图；

图7是示出根据本发明实施例的各种类型的文件系统操作锁及 它们的兼容性的表格；以及

图8是示出了在可实施本发明实施例的计算机系统的方框图。

具体实施方式

在以下描述中，为了说明的目的，阐述了许多具体细节以提供 对本发明实施例的透彻理解。然而，应当清楚，没有这些具体细节 也可以实施本发明的实施例。在其他实例中，为了避免不必要地模 糊这里描述的本发明的实施例，以框图的形式示出了已知结构和装 置。

功能概述

本发明的实施例可对存储在数据库中的文件执行任何有状态 请求，例如NFS文件操作。在执行有状态操作的过程中，数据库服 务器可对资源使用各种基于文件的锁。基于文件的锁不同于数据库 锁，其中，当提交数据库事务时，基于文件的锁不被释放，而是当 资源作为成功执行了NFS CLOSE文件系统操作的对象时被释放。 此外，基于文件的锁可仅在部分资源(例如，文件字节的范围)上 被授权。

在实施例中，在数据库服务器处接收用于执行由数据库服务器 管理的文件操作的请求。请求可以对存储在数据库中的部分文件执 行文件操作。响应于接收该请求，数据库服务器授权仅覆盖包含在 文件操作中的一部分文件的基于文件的锁。例如，数据库服务器可 授权覆盖文件的字节段的基于文件的锁，其中，字节段小于整个文 件。此后，数据库服务器可对文件执行文件操作。一旦文件成为 NFS CLOSE文件系统操作的对象，就对文件释放基于文件的锁。

架构概述

图1是根据本发明实施例的能够处理执行文件系统操作请求的 系统100的方框图。系统100包括客户端110、数据库管理系统 (DBMS)120、和通信链路130。客户端110的用户可向DBMS120 发布指定一个或多个文件系统操作性能的请求。为了说明的目的， 将给出请求符合NFS版本(例如，版本4)的实例。

客户端110可通过能够向DBMS120发布请求的任何介质或机 构来实现。客户端110可向DBMS120发布有状态请求。如本文中 使用的，“有状态请求”是用于执行有状态操作的请求。典型地， 使用有状态协议(例如，NFS)发布有状态请求。客户端110的示 例性实例包括但不限于在可访问通信链路130的装置上执行的应用 程序。虽然为了便于解释在图1中仅示出了一个客户端，但系统100 可包括任意数量的客户端110，其中，每一个均通过通信链路130 与DBMS120进行通信。

客户端110可通过能够同时发布多个请求的介质或机构来实 现。例如，客户端110可对应于在装置上执行的应用程序，并且该 应用程序可以包括每个都可以对DBMS120发送请求的多个进程。 因此，为了避免混淆，这里将术语“请求者”用于指代向DBMS120 发布请求的任何实体。因此，请求者可对应于客户端110、在客户 端110上执行的进程、或由客户端110产生的进程。

DBMS120是便于电子数据的存储和检索的软件系统。DBMS 120包括数据库服务器122和数据库124。使用允许数据库服务器 122处理对保持在数据库124中的文件的任何有状态请求(例如， 用于执行文件操作的请求)的框架(framework)实现数据库服务器 122。

数据库服务器122可在被模拟为多线程服务器的多进程单线程 环境中实现。每个都能够执行工作的进程池位于数据库服务器122 处。当数据库服务器122接收请求时，数据库服务器122可分配进 程池中的任一进程以处理接收到的请求。在多进程单线程环境中实 现数据库服务器122使得数据库服务器122按比例支持大量的客户 端110。

通信链路130可通过提供客户端110和DBMS120之间的数据 交换的任一介质或机构来实现。通信链路130的实例包括但不限于 诸如局域网(LAN)、广域网(WAN)、以太网、或互联网的网络， 或者一个或多个地面、卫星或无线链路。

框架

图2是根据本发明实施例的数据库服务器122的功能部件的方 框图。如上所述，使用允许数据库服务器122处理对保持在数据库 124中的文件的有状态请求的框架200来实现数据库服务器122。 此外，相同的框架200可允许数据库服务器122处理对保持在数据 库124中的数据的无状态请求，例如，以HTTP或FTP协议实现的 请求。此外，如下所述，框架200可被配置为包括附加组件以支持 新的无状态协议或有状态协议，或者以将新的功能添加到由框架 200支持的现有协议。

下面讨论在数据库服务器122的框架200中的每个组件，并且 将在标题为“使用框架处理文件操作”的部分中介绍使用框架200 处理示例性有状态请求的解释。

框架200可由图2中未示出的附加组件来实现，附加组件提供 由有状态或无状态请求所要求的附加功能性。例如，扩展器234是 指可以插入框架200的组件，其允许框架200支持新的无状态或有 状态协议或将新的功能性添加到由框架200支持的现有协议。为了 将扩展组件234插入框架200中，协议解译器210被配置为通过适 当信息在适当时间调用扩展组件234。

协议解译器

协议解译器210接收通过通信链路130发送到DBMS120的数 据包。可使用能够在通信链路130上接收来自客户端110的数据包 的任何软件或硬件组件来实现协议解译器210，并处理如下所述的 数据包。协议解译器210一旦接收到数据包，则识别与该数据包相 关的数据包类型，并将数据包发送到被配置为读取该数据包类型的 数据包的组件。例如，如果协议解译器210通过检查数据包的报头 来确定数据包含有NFS请求，然后协议解译器210向NFS数据包 读取器224发送数据包。在通过NFS数据包读取器224读取包括 NFS请求的数据包之后，NFS数据包读取器224将在数据包内指定 的关于单个文件系统操作的信息送回到协议解译器210，用于进一 步处理。

协议解译器210包括查找机构212。可使用能够存储DBMS120 的请求者的状态信息的任何软件或硬件组件来实现查找机构212。 查找机构可将状态信息存储在易失性存储器中，并可使用便于检索 状态信息的任何机构(例如，B树和哈希表)来实现。在以下标题 为“保存状态信息”的部分中详细表现查找机构212的示例性实施 例。

协议解译器210被配置为处理通过由协议解译器210接收的数 据包请求的操作。协议解译器210可被配置为执行由接收的数据包 请求的操作，或在以下进行进一步的详细解释，协议解译器210可 与框架200的一个或多个组件进行通信以执行通过由协议解译器 210接收的数据包请求的操作。

输出器

可使用能够执行输出操作的任何软件或硬件组件实现输出器 (exporter)220。输出器允许请求者查看目录树的一部分(例如， 属于请求者的目录树)，来代替属于服务器的目录树。

在实施例中，在框架200成功地执行输出操作之后，框架200 向输出操作的请求者发送：(a)识别哪个目录文件夹被输出给请求 者的信息，以及(b)识别请求者是否已经读取和/或写入访问所输 出目录文件夹的信息。当请求者通过输出操作接收对目录文件夹的 访问时，请求者可查看请求者已经访问的目录文件夹的全部内容， 包括任何子目录文件夹。

在实施例中，输出器220可保存关于：(a)哪个请求者输出了 目录文件夹，以及(b)与任一输出目录文件夹相关的访问许可的 信息。目录文件夹可被输出至特定客户端110(例如，将目录文件 夹输出至特定IP地址或域名)或者输出至一个或多个客户端，例如， 通过将目录文件夹输出给IP掩码可将目录文件夹输出给一组相关 机构。

资源锁

可使用能够锁定资源的任何软件或硬件组件来实现资源锁 222。在实施例中，资源锁222被配置为对存储在数据库124中的 文件执行字节段锁定。

当要求对资源执行锁定时，资源锁222执行锁定。在执行对授 权基于文件的锁的请求的过程中，资源锁222可更新通过查找机构 212保存的信息。在下面将进一步详细描述基于文件的锁。

例如，作为一个实施例，协议解译器210可指示资源锁222执 行请求对文件授权基于文件的锁的文件系统操作。资源锁222可以 访问B树以最初确定基于文件的锁是否可被授权，以及如果所请求 的基于文件的锁是可被授权，则资源锁222可以更新一个或多个B 树以反映已对文件授权了基于文件的锁。下面进一步详细描述资源 锁222可访问或更新的特定B树。

数据包读取器

框架200包括多个数据包读取器。每个数据包读取器都被设计 为从符合特定协议的数据包中读取信息。例如，框架200包括NFS 数据包读取器224、FTP数据包读取器226、和HTTP数据包读取 器228。

可使用能够读取和分析符合NFS协议的数据包的任一软件或 硬件组件来实现NFS数据包读取器224。这种数据包可请求一个操 作或多个操作。请求两个或多个文件系统操作的数据包被称作“复 合请求”。NFS数据包读取器224被配置为读取在数据包中指定的 第一操作，并将识别该操作的数据返回到协议解译器210。一旦处 理了在先操作，协议解译器210此后就可以使NFS数据包读取器 224从数据包中读取另一操作。

可使用能够读取和分析包括FTP请求的数据包的任一软件或 硬件组件来实现FTP数据包读取器226。FTP数据包读取器226被 配置为读取和分析包括在FTP数据包内的FTP操作信息，此后将 FTP操作信息传输至协议解译器210，用于处理。

可使用能够读取和分析包括HTTP请求的数据包的任一软件或 硬件组件来实现HTTP数据包读取器228。HTTP数据包读取器226 被配置为读取和分析包括在HTTP数据包内的HTTP操作信息，此 后将HTTP操作信息传输至协议解译器210，用于处理。

虽然图2示出了用于三种不同类型的数据包类型(即，NFS、 FTP、和HTTP数据包)的数据包读取器，但其它实施例可以包括 用于其它类型的数据包的其它数据包读取器。以这种方式，框架可 包括能够读取任一无状态或有状态协议的组件。

特权验证器

可使用能够验证特定请求者是否具有足以执行特定文件系统 操作的许可等级的任一软件或硬件组分来实现特权验证器230。每 次协议解译器210执行文件系统操作时，协议解译器210可指示特 权验证器230来确定特定请求者是否具有足以执行特定文件系统操 作的许可等级。下面将参照图3的步骤318的进一步详细描述讨论 特定用户是否具有足以执行特定文件系统操作的许可等级的确定。

授权器

可使用能够确定发布由协议解译器210接收的特定请求的请求 者实际上是否与在特定请求中识别的请求者相同的任一软件或硬 件组件实现授权器232。以这种方式，在执行请求中指定的任何操 作之前，可通过授权器232验证请求者的身份。每次协议解译器210 接收请求时，协议解译器210都可指示授权器232确定发布由协议 解译器210接收的特定请求的请求者实际上是否与在特定请求中识 别的请求者相同。下面参照步骤316进一步详细描述特定请求是否 由特定客户端110发布的确定。

保存状态信息

在NFS协议中，对已“打开”但还没有“关闭”的文件执行文 件系统操作。在请求者可对文件执行其它文件系统操作之前，请求 者请求执行OPEN文件系统操作以打开文件。在请求者已对文件执 行了所有期望的文件系统操作之后，请求者请求执行CLOSE文件 系统操作以关闭文件。

由数据库服务器执行的文件系统操作可跨越一个或多个数据 库事务。因此，可在文件被打开的时间和文件被关闭的时间之间对 文件执行每一个均改变文件状态的一个或多个数据库事务。

由于NFS是有状态协议，所以框架200必须保存处理有状态请 求时的状态信息。状态信息是描述在任何会话中通过资源的请求者 在先执行的任何动作的信息。根据一个实施例，保存对于请求者已 打开的每个文件的状态信息。例如，如果请求者打开文件A和文件 B，则请求者可使对于文件A的第一组状态信息和对于文件B的第 二组状态信息相关联。

在请求者(a)打开或关闭文件，或者(b)获得关于打开文件 的新锁的任何时间分配或更新状态信息。因此，无论何时只要请求 者(a)打开或关闭文件，或者(b)获得关于打开文件的新锁，状 态信息就被更新以反映对文件执行的有状态操作。

因为文件被打开，所以与请求者相关的状态信息反映了由请求 者对文件执行的所有有状态操作。例如，当请求者第一次打开文件 时，可分配状态信息A。此后，如果相同的请求者获得关于文件的 锁，则状态信息A变为无效，并分配新的状态信息B。注意，状态 信息B反映锁和由请求者打开文件的事实。此后，如果相同的请求 者获得关于文件的第二锁，则状态信息B变为无效，并分配新的状 态信息C。注意，状态信息C反映锁和由请求者打开文件的事实。 当请求者关闭文件时，不再需要保存对于那个请求者、那个文件的 状态信息。

持续请求者与文件关系的状态的跟踪

状态识别数据可附加在客户端110和数据库服务器122之间交 换的通信以提供在通信中参考的文件的当前状态。当请求者打开文 件时，由框架200创建状态识别数据。状态识别数据相对于请求者 已打开的特定文件来识别与特定请求者相关的状态信息。

为了持续跟踪打开文件的状态，将新创建的状态识别数据返回 给请求者。例如，假设请求者XYZ发布打开文件ABC的请求。框 架200生成描述与新打开的文件ABC相关的状态信息的状态识别 数据，并将状态识别数据返回给请求者XYZ。

当请求者将请求传送至数据库122以执行对打开文件的文件系 统操作时，请求包括预先传输给请求者的任何状态识别数据，例如， 状态识别数据可响应于打开文件预先传输给请求者。以这种方式， 请求识别与文件相关的状态信息。例如，如果请求者XYZ发送锁 定文件ABC的请求，则请求将包括响应于数据库服务器122对文 件ABC执行OPEN文件系统操作而预先发送给请求者XYZ的状态 识别信息。框架200可使用包括在请求中的状态识别信息以使用查 找机构212检索对应的状态信息。

因此，如上所述，框架200响应于执行某一有状态文件系统操 作生成状态识别数据，并将生成的状态识别数据传送给文件系统操 作的请求者。此后，请求者可通过包括在请求中的状态识别数据对 相同文件执行附加的有状态文件系统操作，这允许框架200使用状 态识别数据检索文件的状态信息。

当对打开文件执行文件系统操作时，更新与文件相关的状态信 息，以反映文件新的操作状态。创建新的状态识别数据以提供更新 的状态信息。此后，框架200将新的状态识别数据传送给请求者。 以这种方式，仅在请求者和框架200之间交换一组状态识别数据。 在框架成功执行有状态文件系统操作之后，从框架200传送的状态 识别数据识别与作为有状态文件系统操作对象的资源相关的最近 状态信息。

如下一部分中说明的，框架200可将状态信息存储在查找机构 212中，以及可以使用状态识别数据检索存储在查找机构212中的 状态信息。

保存状态信息

根据一个实施例，使用查找机构212来保存状态信息。在一个 实施例中，使用多个B树实现查找机构212。多个B树存储用于处 理有状态文件系统操作请求的状态信息。例如，多个B树可存储请 求者数据、文件数据、和锁数据。请求者数据是用于识别被注册以 发布文件系统操作的请求者的数据。文件数据是用于识别由哪个请 求者打开了哪个文件的数据。锁数据是用于识别对于哪个文件的哪 个锁已被授权给哪个请求者的数据。

在一个实施例中，多个B树包括“client B-tree”、“client_exists B-tree”、“requestor B-tree”、“open_files B-tree”、“opens B-tree”、 “locks_requestor B-tree”、和“granted_locks B-tree”。这些B树中 的每一个都可以存储状态信息，并将在下面进行进一步地描述。

本发明的其它实施例可使用不同组的B树实现查找机构212。 例如，上述多个B树(例如，client_exists B-tree)存储也存储在其 它B树中的信息，因此上述所有B树对于查找机构212的某一实现 来说不是必须的。然而，可以有利地在多于一个B树中存储相同或 相似的信息，这是因为可使用第一环境中的第一密钥更有效地访问 信息，以及可使用第二环境中的第二密钥更有效地访问信息。

在本发明的其它实施例中，可使用多个哈希表代替多个B树实 现查找机构212。实现查找机构212的多个哈希表存储类似于下文 中描述的信息。也可以通过本发明的其它实施例采用其它机构来实 现查找机构212。

CLIENTB-TREE

client B-tree是用于保存关于客户端信息的B树。在client B-tree 内索引项中将反映出向框架200登记的每个客户端110。如下面进 一步详细说明的，客户端110通过发布请求向框架200登记以建立 客户端标识符。client B-tree的密钥是通过数据库服务器预先分配给 客户端的客户端标识符。客户端标识符唯一地识别向框架200登记 的特定客户端110。client B-tree的每个节点都存储关于特定客户端 的信息，包括客户端标识符和客户端提供的标识符，例如，客户端 的网络地址。

CLIENT_EXISTB-TREE

类似于client B-tree，client_exists B-tree保存关于客户端的信 息。虽然client B-tree和client_exists B-tree都保存关于客户端的信 息，但client_exists B-tree的密钥是客户端提供的标识符。例如，客 户端提供的标识符可以是客户端的网络地址。

client_exists B-tree可用于基于客户端提供的标识符来确定特 定客户端110是否已向框架200登记。client_exists B-tree的每个索 引项也都存储关于特定客户端的信息，包括客户端标识和客户端提 供的标识符。

REQUESTOR B-TREE

requestor B-tree是保存关于请求者的信息的B树。requestor B-tree的密钥反映与请求者相关的客户端标识符和唯一识别请求者 的请求者标识符。requestor B-tree可用于确定与特定客户端110相 关的所有请求者，这是在处理OPEN文件系统操作期间或在覆盖已 成为不可操作的客户端时所需要的。

requestor B-tree的每个索引项都存储关于请求者的信息。例如， 对应于特定请求者的requestor B-tree的索引项可存储关于以下各项 信息：哪个客户端与请求者有关、何时接收到来自请求者的最后通 信、请求者打开了哪个文件、以及什么状态信息与请求者相关。

OPEN_FILES B-TREE

open_files B-tree是保存关于已打开的文件的信息。open_files B-tree的密钥是文件的文件句柄。open_files B-tree可用于确定可否 对特定文件执行文件系统操作。open_files B-tree的每个索引项都可 以存储关于打开文件的信息。例如，这种信息可包括对于打开文上 的基于文件的锁的数量、对于打开文件的基于文件的锁的类型、什 么状态识别数据识别与打开文件相关的状态信息、用于打开文件的 对象标识符。

OPENS B-TREE

opens B-tree是保存关于已打开文件的信息的B树。opens B-tree 的密钥是状态识别数据。通过遍历opens B-tree，可以定位关于与状 态信息相关的打开文件的信息，该状态信息通过用作opens B-tree 的密钥的状态识别数据来识别。

例如，假设客户端已经打开特定文件。对于客户端保存的状态 信息将表示客户端已打开了特定文件。状态信息将被分配给一组状 态识别数据。状态识别数据可用于遍历opens B-tree以找到表示特 定文件打开的索引项。

opens B-tree的每个索引项都存储关于打开文件的信息，例如， 识别与打开文件相关的状态信息的状态识别数据、打开了打开文件 的请求者、文件是否被打开以用于读或写、打开文件是否被修改、 以及读或写是否被除打开了打开文件的请求者之外的任何其他请 求者拒绝。

为了打开文件，生成状态识别数据以识别打开文件。状态识别 数据(a)被传送至请求打开文件的请求者，以及(b)用于将条目 添加到opens B-tree以反映文件已被打开。

LOCKS_REQUESTOR B-TREE

locks_requestor B-tree是保存关于锁请求者的信息的B树。对 locks_requestor B-tree的密码是状态识别数据。Locks B-tree的每个 索引项都包括关于锁的请求者的信息，例如，客户端标识符、请求 者标识符、以及锁所有者标识符。锁所有者标识符唯一地识别被授 权锁定的特定请求者。客户端标识符和请求者标识符由框架200分 配，并且锁所有者标识符由请求者提供。

GRANTED_LOCKS B-TREE

granted_locks B-tree是保存关于授权锁的信息的B树。 granted_locks B-tree的密钥是文件句柄。granted_locks B-tree可用于 迅速确定哪个基于文件的锁(如果有的话)已被特定文件授权。

当协议解译器210指示资源锁222执行请求特定锁授权的文件 系统操作，资源锁222可访问查找机构212的一个或多个B树。作 为实例，假设协议解译器210接收了对文件的特定锁授权的请求， 此后，协议解译器210指示资源锁222处理文件系统操作。资源锁 222可初始确定是否已经通过访问granted_locks B-tree对文件授权 了抵触锁。资源锁222可使用由文件系统操作识别的文件的文件句 柄来遍历granted_locks B-tree。如果granted_locks B-tree中的条目 存在文件句柄，则条目的检查将通知资源锁222是否已对文件授权 了抵触锁。

如果资源锁222确定还没有对文件授权抵触锁，则资源锁222 可以(a)生成新的状态识别数据以识别资源的新状态，以及(b) 将条目加入granted_locks B-tree以反映所请求锁的授权。资源锁222 可使用新生成的用于资源的新状态识别数据将新条目加入 granted_locks B-tree，此后，从由在先状态识别数据参考的locks B 树中删除在先条目。Locks B树中的新条目包括对在资源上执行的 所有在先有状态涉及的参考，因此没有必要存储由在先状态识别数 据涉及的项。

使用框架处理文件操作

图3是示出根据本发明实施例的用于处理文件系统操作的步骤 的流程图。通过执行图3的步骤，可通过DBMS120执行诸如有状 态NFS操作的有状态操作。

一般来说，框架保存关于框架执行的操作的信息。一旦执行了 有状态操作，框架就返回对应于操作状态的请求者状态识别数据。 在对于有状态操作的后续请求中，请求者将状态识别数据发送回框 架。然后，框架将状态识别数据用作密钥以识别应用于该后续请求 的操作的状态信息。

获得框架生成的客户端标识符

参照图3，首先，在步骤310中，在数据库服务器处接收用于 建立请求者的客户端标识符的第一请求。可通过协议解译器210执 行步骤310，其中，协议解译器210通过通信链路130接收由客户 端110发送的包括第一请求的数据包。

协议解译器210可接收各种数据包类型的数据包。虽然协议解 译器210被配置为识别所接收数据包的数据包类型，但协议解译器 210无需配置为读取每种数据包类型。例如，协议解译器210可通 过检查包含在数据包报头内的信息来确定所接收数据包的数据包 类型。一旦协议解译器210确定所接收数据包的数据包类型，协议 解译器210就将该数据包发送到用于读取该数据包类型的数据包的 组件。

为了说明的目的，应当假设在步骤310中接收的数据包是包括 对请求者建立客户端标识符的请求的NFS数据包。建立客户端标识 符是NFS操作。在这些条件下，协议解译器将数据包发送到NFS 数据包读取器224以读取该数据包。NFS数据包读取器224读取并 解析数据包，并将识别所请求文件系统操作(即，建立客户端标识 符)的数据发送回协议解译器210。

在接收识别文件系统操作的数据之后，协议解译器210处理文 件系统操作。在本实例中，协议解译器210处理请求以建立客户端 标识符。例如，作为处理请求的一部分，协议解译器210可查阅查 找机构212以确定(a)是否已对请求者建立客户端标识符，以及 (b)如果还没有对请求者建立客户端标识符，则确定哪个客户端 标识符应该与请求者相关。

在实施例中，数据库服务器可基于客户端提供的标识符(例如， 客户端的网络地址)遍历client_exists B-tree，以确定是否已为特定 请求者建立客户端标识符。如果还没有为请求者建立客户端标识 符，则数据库服务器可为客户端生成客户端标识符。在为客户端生 成客户端标识符之后，数据库服务器可将索引项加入client B-tree 和client_exists B-tree，以存储关于分配给请求者的新客户端标识符 的信息。

在执行步骤310之后，处理进入步骤312。在步骤312中，在 上述步骤310中建立的客户端标识符被传送至请求者。可通过协议 解译器210执行步骤312，协议解译器210通过通信链路130将包 括客户端标识符的通信传送至请求者。在实施例中，请求者可通过 将附加通信与数据库服务器122交互来验证由数据库服务器122接 收的客户端标识符，从而验证客户端标识符。在执行步骤312之后， 处理前进到步骤314。

接收复合请求

在步骤314中，接收用于执行文件系统操作的第二请求。可通 过协议解译器210执行步骤314，该协议解译器210通过通信链路 130接收包括由客户端110发送的第二请求的数据包。第二请求包 括客户端标识符。

为了示出复合请求的处理，假设在步骤314中接收的第二请求 是包括两个或多个文件系统操作的复合请求。由框架200顺序地处 理在复合请求中指定的文件系统操作。

为了示出有状态文件系统操作请求的处理，进一步假设在第二 请求中指定的第一文件系统操作是对已由请求者预先打开的文件 的基于文件的锁的请求。在框架200打开文件后，框架200(a)生 成识别与打开的文件相关的状态信息的状态识别数据，以及(b) 将状态识别数据传送至请求者。因此，如果在步骤314中接收的请 求是用于对打开文件执行文件系统操作的请求，则在步骤314中接 收的请求包括预先发送给请求者的状态识别数据。在该实例中，状 态识别数据将允许框架200参考与文件相关的状态信息，该文件是 请求基于文件的锁的对象。

在协议解译器210确定步骤314的请求包括文件系统操作请求 之后，协议解译器212可将包括步骤314的请求的数据包发送到 NFS数据包读取器224，以读取数据包。此后，NFS数据包读取器 224向协议解译器210传送关于在数据包中指定的第一未处理文件 系统操作(下文中称作“当前”文件系统操作)的信息。如下面进 一步详细描述的，在处理了当前文件系统操作之后，框架200应该 处理在数据包中指定的其它未处理文件系统操作。

为会话分配请求

一旦协议解译器210接收到关于在来自NFS数据包读取器224 的复合请求中指定的当前文件系统操作的信息时，协议解译器210 将当前文件系统操作分配给数据库会话。可从数据库会话池中选出 的分配数据库会话是数据库服务器将处理包括在复合请求中的文 件系统操作的会话。因为状态信息独立于会话保存(如上所述，状 态信息被保持在查找机构212中)，所以可从数据库会话池中选择 任一会话，以服务当前文件系统操作。在执行步骤314之后，处理 前进到步骤316。

鉴别客户端

在步骤316中，进行步骤314中接收的请求是否是由包括在请 求内的客户端标识符识别的客户端发布的确定。在实施例中，每次 接收到请求，就鉴别请求以确认请求者的身份。步骤316可通过与 授权器232通信的协议解译器210执行，以使授权器232鉴别请求。 授权器232可使用包括在鉴别进程中的请求内的客户端标识符。在 授权器232鉴别了步骤314中接收的请求之后，授权器232将鉴别 进程的结果传输至协议解译器210。授权器232可使用标准鉴别库 和协议(包括Kerberos、LIPKEY、和SPKM-3)来鉴别请求者。

如果授权器232未鉴别在步骤314中接收的请求，则协议解译 器210将通信发送到发送第二请求(在步骤314中接收的)的请求 者，以通知请求者未鉴别第二请求。一旦鉴别了第二请求，则处理 前进到步骤318。

确定所请求的操作是否被允许

在步骤318中，进行请求者是否具有足以执行当前文件系统操 作的许可等级的确定。步骤318可以通过与特权验证器230通信的 协议解译器210执行，以使特权验证器230验证请求者是否具有足 以执行当前文件系统操作的许可等级。

在实施例中，特权验证器230使用对每个请求者的访问控制列 表确定请求者是否具有足以执行特定文件系统操作的许可等级。特 权验证器230保存每个请求者的访问控制列表。每个访问控制列表 均包括访问控制条目(ACE)的列表。每个ACE识别请求者是否 被授权或被拒绝授予特定特权。

作为实例，假设请求者1234发布了请求以执行请求特权A和 特权B的文件系统操作。特权验证器230保存对请求者1234的ACE 列表。特权验证器230顺序处理在访问控制列表中指定的ACE。如 果对请求者1234的访问控制列表包括：表示请求者1234被授权许 可A的第一ACE、表示请求者1234被授权许可B的第二ACE、和 表示请求者1234被拒绝授予许可A的第三ACE，然后特权验证器 230确定请求者1234具有足以执行请求的文件系统操作的许可等 级，这是因为特权验证器230将顺序处理在访问控制列表中的ACE 直到可以作出决定。因此，一旦特权验证器230读取了对请求者1234 的访问控制列表中的第二ACE，特权验证器230就可以进行关于请 求者1234是否具有足以执行请求的文件系统操作的许可等级的确 定，并且特权验证器230将不会读取访问控制列表的剩余部分。在 执行步骤318之后，处理前进到步骤320。

定位适当的状态信息

在步骤320中，如果执行当前文件系统操作需要状态信息，则 基于包含在第二请求内的状态识别数据来检索适当的状态信息。状 态识别数据可被预先分配并与请求者通信，例如，请求者可预先打 开文件或者可以预先授权文件上的锁。如果请求是复合请求，则在 步骤320中检索的状态信息可与当前文件系统操作相结合。可通过 使用查找机构212检索状态信息的协议解译器210执行步骤320。 在步骤320中检索的状态信息包括执行当前文件系统操作所需的任 何状态信息。在处理步骤320之后，处理前进到步骤322。

执行请求的文件系统操作

在步骤322中，基于适当状态信息在选取的数据库会话内处理 当前文件系统操作。在一个实施例中，可通过协议解译器210自身 执行步骤322。在另一实施例中，协议解译器210可与框架200的 其它组件通信，以使其它组件执行当前文件系统操作。在处理了当 前文件系统操作之后，处理前进到步骤324。

更新状态信息

在步骤322中，在会话中执行文件系统操作。会话使用的状态 由于文件系统操作的执行而改变。在本实施例中，表示会话状态的 状态信息被称作“更新的状态信息”。更新的状态信息反映了由当 前文件系统操作的处理所产生的状态改变。例如，更新的状态信息 反映了作为文件系统操作对象的文件是否已被打开，以及是否已对 文件授权了任何锁。然后，在根据文件执行了当前文件系统操作之 后，更新的状态信息反映了文件的当前状态。

在步骤324中，更新存储在查找机构212中的信，以反映与当 前文件系统操作相关的更新的状态信息。在实施例中，更新包括查 找机构212的一个或多个B树，以表示会话的新状态。可通过(a) 生成新的状态识别数据以识别更新的状态信息，以及(b)更新或 添加条目到查找机构212的适当B树以反映更新的状态信息来更新 包括查找机构212的B树。

例如，假设在步骤322中，在步骤322中处理的当前文件系统 操作是用于对特定文件的前100个字节执行基于文件的锁的操作。 资源锁222可首先确定是否已通过访问granted locks B-tree对文件 授权抵触锁。资源锁222可使用在当前文件系统操作中识别的文件 的文件句柄遍历granted locks B-tree。如果granted locks B-tree中的 条目存在文件句柄，则条目的检查将通知资源锁222是否已对文件 上授权抵触锁。

如果资源锁222确定还没有对文件授权抵触锁，则资源锁222 (a)生成新的状态识别数据以识别资源的新状态，以及(b)将条 目添加到granted locks B-tree以反映所请求锁的授权。具体地，资 源锁222可使用新生成的资源的新状态识别数据将新条目添加到 granted_locks B-tree，此后，删除由先前状态识别数据涉及的locks B-tree中的先前项。除对资源授权的任一先前锁之外，granted locks B-tree中的新条目包括对文件的前100字节授权的基于文件的锁的 参考，因此不必存储由在先状态识别数据涉及的条目。

在执行步骤324之后，处理前进到步骤326。

重复复合请求中指定的操作

每个请求都可以是指定将执行的一个或多个文件操作系统的 复合请求。在步骤326中，如果步骤314中接收的请求是复合请求， 并且存在复合请求中指定的其它未处理的文件系统操作，则处理进 入步骤318，其中，在步骤314的第二请求中指定的下一未处理的 文件系统操作成为“当前文件系统操作”。以这种方式，由框架200 顺序地处理在复合请求中指定的每个文件系统操作。

在处理了步骤314的第二请求中指定的所有文件系统操作之 后，处理前进到步骤328。

为请求者提供结果和修订状态标识符

在步骤328中，执行在步骤314的请求中指定的所有文件系统 操作的结果被传送至通信中的请求者。通信可包括识别状态信息的 任何状态识别数据，该状态信息被分配到成功执行文件系统操作的 对象的特定资源。步骤328的实施可通过协议解译器210执行，协 议解译器210向请求者发送处理复合请求的每个文件系统操作的结 果，以及响应于执行有状态文件系统操作生成的任何状态识别数 据。例如，如果请求者请求对请求者预先打开的文件的特定字节段 授权读-写锁，则协议解译器210可通过向请求者发送通信来执行步 骤328，该通信包括识别资源的新状态(即，对特定文件的特定字 节段授权读-写锁的确认)的新状态识别数据。注意，响应于有状态 文件系统操作的成功处理，而不是响应于无状态文件系统操作的成 功处理，新的状态识别信息被传送给请求者。

在NFS协议中，可在单个通信中将处理在复合请求中指定的多 个文件系统操作的结果传送给请求者，因此，可通过包括用于在复 合请求中指定的每个成功执行的有状态文件系统操作的状态识别 信息的通信在单个通信中发送在步骤328中传送给请求者的状态识 别数据。

如果框架200不能处理复合请求中的特定文件系统操作，则将 单个通信传送给请求者。通信包括描述(a)在处理复合请求中指 定的文件系统操作的、包括任何新状态识别信息的结果的信息，以 及(b)表示不能执行文件系统操作的信息的信息。

使用框架处理无状态事务

框架200也可以处理无状态请求，例如，无状态文件系统操作 或符合无状态协议的请求。当协议解译器210接收包括无状态请求 的数据包时，协议解译器210可将数据包传送到用于读取和解析数 据包的组件。例如，协议解译器210将包括FTP请求的数据包发送 至FTP数据包读取器226，以及协议解译器210将包括HTTP请求 的数据包发送至HTTP数据包读取器228。

在读取和解析无状态请求之后，FTP数据包读取器226和HTTP 数据包读取器228将识别无状态请求的信息传送到协议解译器210。 协议解译器210又可以执行无状态请求或与框架210的另一组件进 行通信以执行无状态请求，例如，资源锁222可请求锁定资源。因 为请求是无状态的，所以一旦请求被成功执行，就无需将状态信息 分配给请求。

文件系统操作和数据库事务之间的关系

当客户端希望写文件时，客户端可请求执行OPEN文件系统操 作、然后执行多个写文件系统操作、然后执行CLOSE文件系统操 作。为了该部分的目的，单个文件系统操作涉及多个NFS操作，从 OPEN文件系统操作开始到相应的CLOSE文件系统操作。为了执 行单个文件系统操作，可请求数据库服务器122执行一个或多个数 据库事务。在执行文件系统操作之前提交一个或多个数据库事务中 的每一个。因此，在知道文件系统操作的执行是否成功之前提交通 过特定数据库事务对数据库124进行的改变。

因此，如在以下多个部分中的进一步详细说明的，想要查看资 源的请求者可以期待查看(a)当前反映任一提交的数据库事务的 资源的版本，或(b)仅反映完成的文件系统操作的资源的版本， 而不反映对应于尚未完成的文件系统操作的任何提交的数据库事 务。

打开提交后的改变

请求者可单独对相同的资源发布OPEN和CLOSE命令。因此， 即使CLOSE命令可以相对于一个请求者关闭文件，但仍可以相对 于所有请求者关闭文件。术语“最后关闭”是指导致文件对于所有 请求者关闭的CLOSE文件系统操作。因此，当前由一个或多个请 求者打开的任何资源还没有对资源执行最后关闭。

可在打开文件的时刻和最后关闭的时刻之间执行每一个都改 变文件状态的多个数据库事务。对文件执行的改变可对文件执行最 后关闭之前提交。(1)已经在数据库中提交，但(2)包括还没有 执行最后关闭的文件的改变在这里被称作“打开提交后的改变”。

不一致客户端

当还没有对资源执行最后关闭并且请求者发送请求以获得资 源时，请求者将接收的资源状态取决于与请求者相关的客户端类 型。“不一致客户端”是期望查看资源“当前状态”的客户端。在 本文中，资源的当前状态包括对资源作做的任何打开提交后的改 变，但并不包括对资源所做的任何未提交改变。

例如，如果因为资源首先被打开使得两个提交事务的数据库改 变了资源状态，并且还没有对资源执行最后关闭，则对资源发布请 求的不一致客户端期望查看反映由两个数据库事务进行的改变的 资源状态。使用NFS、FTP、或HTTP协议访问DBMS120的客户 端是不一致客户端的实例。与不一致客户端相关的请求者将是不一 致请求者，即，请求者期望查看资源的当前状态。

一致客户端

一致客户端是不允许查看任何打开提交后的改变的客户端。相 反，一致客户端仅(a)如果资源已被打开但还没有被关闭，则在 资源被打开之前，或者(b)在已对资源执行了最后关闭之后查看 提交的对资源进行的改变。例如，假设已经打开了资源，但还没有 对资源执行最后关闭。请求访问资源的一致客户端期望查看仅在执 行OPEN操作之前的资源状态。

因此，如果因为资源被打开使得两个提交的数据库事务改变了 资源状态，并且还没有执行最后关闭，则发布请求资源的一致客户 端期望查看不反映由两个事务完成的改变的资源状态。为了简化说 明，必须由一致客户端看到的资源状态应被称作资源的“关闭提交” 版本。

使用SQL协议访问DBMS120的客户端是一致客户端的实例。 与一致客户端相关的任何请求者将是一致请求者，即，请求者期望 查看处于关闭提交状态的资源状态。

为了进一步举例说明，以下文件系统操作和时间点按以下顺序 发生：

(1)时间t1

(2)请求者1打开文件f1

(3)请求者1提交对文件f1的改变

(4)时间t2

(5)请求者2打开文件f1

(6)请求者2提交对文件f1的改变

(7)时间t3

(8)请求者1关闭文件f1

(9)时间t4

(10)请求者2关闭文件f1

(11)时间t5

在时间t3，文件f1的一致版本是在t1处的文件，以及文件的 不一致版本是时间t3处的文件。在时间t4，文件f1的一致版本是 时间t1处的文件，以及文件的不一致版本是时间t4处的文件。在 时间t5，文件f1的一致版本是时间t5处的文件，以及文件的不一 致版本是时间t5处的版本。因为一致客户端期望查看资源的在先状 态，所以该状态必须被保存直到对资源执行了最后关闭。

重构关闭提交后的版本

为了以框架200支持一致请求者和不一致请求者，框架200使 用不同类型的锁，即，数据库锁和基于文件的锁。数据库锁是响应 于执行数据库操作得到的锁，并且数据库锁在成功完成(提交)数 据库操作时被释放。基于文件的锁是响应于执行OPEN文件系统操 作得到的锁，并且基于文件的锁在执行CLOSE文件系统操作时被 释放。

图4是示出了根据本发明实施例的使用数据库锁和基于文件的 锁的功能步骤的流程图。在步骤410中，请求者请求包括特定资源 的操作。可经由通信链路130通过客户端110向数据库服务器122 发送请求来执行步骤410。在执行步骤410之后，处理前进到步骤 412。

在步骤412中，进行请求者的请求类型的确定。可通过数据库 服务器122执行步骤412。基于请求者类型，数据库服务器122确 定哪个版本的特定资源发送给请求者。如果请求者是不一致请求 者，则数据库服务器122发送当前版本的特定资源。然而，如果请 求者是一致请求者，则数据库服务器122发送较老版本的特定资源， 即，关闭提交后的版本的资源。

可基于请求符合的协议类型完成请求者类型的确定。如果请求 符合SQL协议，则请求者是一致请求者。然而，如果请求符合NFS、 FTP、或HTTP协议，则请求者是不一致请求者。在执行步骤412 之后，处理前进到步骤414。

在步骤414中，为了执行请求的操作，获得对于特定资源的第 一锁。第一锁是第一种类型的锁，例如，基于文件的锁。在执行步 骤414之后，处理前进到步骤416。

在步骤416中，为了执行由请求操作要求的每个数据库操作， 获得第二锁。第二锁是第二种类型的锁，例如，数据库锁。

在实施例中，在执行改变特定资源状态的任何数据库操作之 前，将资源的临时拷贝存储在数据库124中。当对特定资源授权了 基于文件的锁时，对特定资源的改变反映在资源的临时拷贝中而不 在真实的资源本身中。因为资源的原始版本保持未被修改，所以可 通过服务一致请求者的数据库服务器122使用原始版本。数据库服 务器122可以使用服务不一致请求者的资源的临时拷贝，这是因为 临时拷贝反映了已经由提交的数据库操作对资源所做的所有改变。 在执行步骤416之后，处理前进到步骤418。

在步骤418中，响应于相应数据库操作的成功完成，释放数据 库锁。当由数据库系统执行操作时，数据库系统提交用于执行操作 的事务，并释放对在操作期间修改的所有资源上保存的数据库锁。 在执行了由请求的操作要求的所有数据库操作之后，处理前进到步 骤420。

在步骤420中，响应于文件系统操作的成功完成，释放基于文 件的锁。具体地，当对资源执行最后关闭时，释放资源上的基于文 件的锁，并且资源的临时拷贝可被建立为资源的当前版本。例如， 通过拷贝对于原始拷贝的临时拷贝，然后删除临时拷贝，临时拷贝 可被建立为当前版本。

在执行文件系统操作之后，资源的不一致版本和资源的关闭提 交后的版本是相同的。因此，可使用资源的原始版本服务一致请求 者和不一致请求者，直到资源再次被打开。

通过执行图4的步骤，基于文件的锁和数据库锁可用于使数据 库服务器122能够服务一致请求者和不一致请求者。当保存资源上 的基于文件的锁时，保持在执行OPEN文件系统操作之前的资源状 态，由此允许数据库服务器122服务一致请求者。

管理并发的访问

当多个请求者执行包括相同资源的操作时，使用基于文件的锁 同样是有利的。例如，多个请求者中的每一个都可以发布请求以对 相同的文件执行文件系统操作。多于一个请求者可以打开文件，并 且多于一个请求者可以改变资源的状态。

作为实例，假设第一请求者打开了文件并对文件做出改变。当 第二请求者向数据库服务器122发送相同文件版本的请求时，数据 库服务器122确定第二请求者的请求者类型。如果第二请求者是一 致请求者，则数据库服务器122提供未反映打开了文件之后由第一 请求者对文件所做的任何改变的文件的版本。如果第二请求者是不 一致请求者，则数据库服务器122提供反映打开了文件之后由第一 请求者对文件所做改变的文件的版本。

在以下标题为“执行事务语义”的部分中描述关于在资源作为 基于文件的锁的对象时数据库服务器如何可保存资源状态的进一 步信息。

执行事务语义

存在保存关于资源作为OPEN文件系统操作的对象时的资源 的在先版本的信息是有利的许多原因。首先，如上所述，保存资源 作为OPEN文件系统操作的对象而不是最后关闭的对象时的资源的 在先版本，使数据库服务器122服务来自一致请求者的资源请求。 其次，保持资源的在先版本使数据库服务器将资源恢复到在先版 本。例如，当(a)请求者创建不正确版本的资源，(b)请求者创 建与模式不兼容的版本的基于模式的资源，或(c)由多个请求者 对资源执行的改变彼此不兼容时，有必要在各种环境中将资源恢复 到在先版本。

明显地，需要从资源中去除以将资源恢复到在先状态的改变可 以包括提交的改变。因此，由数据库系统用来去除由未提交的事务 进行的改变的传统取消机构不足以执行必要的恢复。

本发明的实施例有利地使资源恢复到在先状态，即使已经执行 了从在先状态改变资源状态的提交的数据库事务。根据本发明的实 施例，通过提交的数据库事务对资源完成一个或多个改变。在提交 的数据库事务改变资源的状态之后，接收到将资源恢复到由提交的 数据库事务作出的改变之前的状态的请求。例如，客户端110可对 数据库服务器122发布请求以将特定文件恢复到特定时间点之前的 状态，例如，文件的关闭提交后的版本。

响应于接收请求，资源被恢复到特定时间点(例如，当文件被 打开的时间点)之前的状态。在恢复资源的过程中，资源的当前状 态停止以反映由提交的数据库事务对文件作出的改变。用于将资源 恢复到在先状态的技术将在下一部分中进一步详细讨论。

资源恢复技术

各种技术可用于将资源恢复到特定时间点之前的状态。例如， 使用的特定技术可依赖于资源是基于模式的资源还是不基于模式 的资源。基于模式的资源是符合定义模式的资源。例如，符合给定 模式的购货订单文档是基于模式的资源的实例。不基于模式的资源 是不是基于模式的资源的任何资源。

以解构形式存储资源

可以构造形式通过存储整个资源(例如，将XML文档存储在 数据库表的lob列中)一起来存储基于模式的资源。可选地，可有 利地通过分别存储包括基于模式的资源的元素来以解构形式存储 基于模式的资源。例如，描述XML文档的各个XML标签的数据 及其相关数据可被存储在数据库表的列中。因为分别存储基于模式 的资源的元素，所以基于模式的资源的元素可以需要在读取基于模 式的资源之前被重构。

图5示出了示出用于以解构形式存储基于模式的资源的机构的 资源表。图5的表包括参考列504。描述基于模式的资源的数据可 被存储在资源表中或由资源表参考。例如，资源表的参考列504包 括识别另一表的指针506，即，XML类型表510，其中，存储关于 基于模式的资源的数据。XML类型表510自身可以参考存储基于 模式的资源的其它数据元素的一个或多个其它表。例如，通过对嵌 套表520的引用512示出了XML类型表510。

XML类型表510和任何嵌套表502存储关于基于模式的资源 元素的数据。当请求者想要读取基于模式的资源的前100字节时， 资源必须被重构以服务该请求，这是因为XML类型表510并不存 储用于描述基于模式的资源的每个数据元素出现在哪个字节的信 息。因此，当从基于模式的资源中读取数据时，基于模式的资源必 须被重构并被存储在XML的lob列502中。如果请求者想要读取 基于模式的资源的前100字节，则这种请求可容易地通过读取存储 在XML的lob列502中的解构资源的前100字节由数据库服务器 122执行。

如下面进一步详细说明的，可在存储在XML的lob列502中 的资源的解构拷贝上执行后续操作，同时留下完整地存储在XML 类型表510和任何嵌套表520中的资源的解构元。

恢复基于模式的资源

根据一个实施例，基于“在先版本信息”恢复基于模式的资源。 图5是根据本发明实施例的存储用于基于模式的资源的在先版本信 息的系统的方框图。在先版本信息可保存在XML类型表510和任 何嵌套表520中，同时可对存储在XM的lob列502中的资源的重 构拷贝执行对基于模式的资源的改变，直到对基于模式的资源执行 最后关闭。

在本发明的实施例中，当对资源授权基于文件的锁时，立即在 执行可改变资源状态的数据库操作之前，创建基于模式的资源的构 造拷贝。例如，基于模式的资源的构造拷贝可被创建并存储在XML 的lob列502中。

此后，资源的构造拷贝(存储在XML的lob列502中的资源 拷贝)被作为资源的当前版本，并对资源的构造拷贝(存储在XML 的lob列502中的资源拷贝)作出数据库操作所需的改变。实际上， XML的lob列502中的资源拷贝成为资源脏版(dirty version)的高 速缓存。注意，基于模式的资源的解构版本仍被保持在XML类型 表510中。

为了将基于模式的资源恢复为资源的解构版本，删除存储在 XML的lob列502中的资源拷贝。此后，将存储在XML类型表510 和任何嵌套表520中的资源的解构版本作为资源的当前版本，来代 替存储在XML类型表510中的构造拷贝。

当地资源执行CLOSE文件系统操作时，对存储在XML类型 表510中的资源的解构拷贝作出的改变可通过改变存储在XML类 型表510和任何嵌套表520中的资源的解构版本而变得持久，以反 映存储在XML的lob列502中的资源的构造拷贝。

使用瞬像时间以恢复不基于模式的资源

图6A和6B是根据本发明实施例的存储不基于模式的资源的 在先版本信息的方框图。图6A和6B用于讨论用于存储不基于模式 的资源的在先版本信息的三种不同方法。

根据第一种方法，如图6A示出，资源表600将不基于模式的 资源存储在LOB列602中。在该方法中，当对资源执行OPEN文 件系统操作时，瞬像时间被存储在资源表600的列604中。瞬像时 间表示紧接着对资源执行OPEN文件系统操作时之前的逻辑时间。

在授权一个或多个数据库事务改变资源之后，数据库事务可以 不是“未完成”，但因为瞬像时间，资源可被恢复为使用与资源相 关的取消信息的瞬像时间的状态。未完成信息是指由DBMS120保 存的、可用于“重算”或取消已执行但未授权的数据库事务。

瞬像时间和取消信息用于将一组改变应用于资源以改变资源 的状态，以反映瞬像时间时的资源状态。一旦恢复了资源以反映在 瞬像时间时的资源状态，就从资源表600的列604中去除瞬像时间。

在实施例中，“倒叙查询”可用于将一组改变应用于资源以改 变资源的状态，从而在瞬像时间时反映资源的状态。用于执行倒叙 查询的技术在2003年4月30日提交的标题为“Flashback Database” 的美国专利申请序列第10/427,511号中进行了描述，其全部内容结 合于此作为参考。

将高速缓存列用于恢复不基于模式的资源

如图6B所示，根据第二种方法，资源表650将不基于模式的 资源存储在LOB列652中。在该方法中，当对资源执行OPEN文 件系统操作时，将资源的拷贝存储在资源表650的列654中。列654 被用作“高速缓存列”。具体地，存储在列654中的资源拷贝被作 为资源的当前版本。当数据库事务影响对资源的改变时，对存储在 列654中的资源拷贝而不是存储在列652中的原始资源作出改变。

如果对资源执行CLOSE文件系统操作，则存储在654中的资 源拷贝可被存储在列652中，因此原始资源将反映对通过提交的数 据库操作对资源作出的任何改变。直到执行了CLOSE文件系统操 作，存储在列652中的资源的当前值反映恰好在执行OPEN文件系 统操作之前的资源状态。因此，如果需要将资源恢复到恰好在执行 OPEN文件系统操作之前的资源状态，则需要发生对资源表650的 改变仅将去除存储在列654中的资源拷贝。在对资源执行最后关闭 之前，不一致请求者可查看列654中的资源拷贝，以及一致请求者 可查看存储在列652中的资源。

混合方法

由于存储空间的限制，比某一时间更早的取消信息典型地被较 新的取消信息重写。因此，使用瞬像时间执行恢复(即，第一种方 法)并不总是可行的。然而，当取消信息可用时，基于瞬像时间的 恢复可优于高速缓存列恢复(即，第二种恢复)。

因此，在第三种(混合)方法中，除非数据库服务器122确定 资源的取消信息在资源需要被恢复时不可用，否则就执行上述基于 瞬像的方法。如果数据库服务器122确定资源的取消信息在资源需 要被恢复时不可用，则上述的高速缓存列方法随后被执行。

如果被数据库服务器122保存的取消信息的时间总量小于可配 置的时间总量，则数据库服务器122可以确定资源的取消信息在资 源需要被恢复时不可用。

一致性检查

根据一个实施例，在文件关闭时检查修改文件的一致性，并且 不再存在待决的OPEN文件系统操作。例如，可检查基于模式的资 源，以保证基于模式的资源符合模式的规则。如果基于模式的资源 不符合相应的模式，则资源可被恢复到在其被打开时的资源状态。

如上所述，如果资源是授权的基于文件的锁的对象并且请求者 发布请求以将资源恢复到较早状态，或者如果资源的一致性检查失 败，则如上所述，资源可被恢复到较早的状态。下面将描述基于文 件的锁的进一步细节和优点。

基于文件的锁

基于文件的锁能够使数据库服务器122对保存在数据库124中 的文件执行文件系统操作。资源锁222可管理对存储在数据库124 中的资源的文件系统锁。基于文件的锁的性态在三个重要方面不同 于用于无状态协议(例如，HTTP)的其它锁。

首先，可对一部分资源而不是仅在全部资源上授权基于文件的 锁。具体地，可在资源上的字节段内授权基于文件的锁。因此，单 个文件可以是多个基于文件的锁的对象，其中，每个基于文件的锁 覆盖文件的不同字节段。

第二，基于文件的锁是以租用为基础的，这意味着一旦对请求 者授权特定的基于文件的锁，则在特定文件锁定期满之后，在第一 周期授权特定锁。然而，由请求者接收的任何通信更新第二周期的 特定锁。因此，在文件系统锁定期满之前，只要请求者与数据库服 务器122进行通信，请求者就可不断地更新基于文件的锁。

一旦特定文件系统锁定期满，就更新查找机构212以反映不再 授权特定文件锁。可周期性地检查保存在查找机构212内的数据以 保证通过请求者请求的每个锁仍然有效。

当特定请求者请求与先前授权的另一锁相抵触时，可检查先前 授权的锁以保证先前授权的锁仍然有效。如果先前授权的锁不再有 效，则更新存储在查找机构212中的信息以反映该锁无效(例如， 可删除关于锁的信息)。同样，当特定客户端期满时，释放已对特 定客户端授权的所有锁。在实施例中，因为客户端最后与框架200 通信，所以客户端可在经历了时间的可配置量之后期满。因此，如 果先前授权的锁与请求授权的锁相抵触，则可检查与先前授权的锁 相关的客户端以验证该客户端仍然有效。如果客户端无效，则释放 先前授权的锁，并且可执行请求被授权的锁。在本发明的实施例中， 可通过检查客户端B树执行特定客户端是否已经期满的确定。

对于无状态协议锁的基于文件的锁的第三个区别是没有仅提 供读取访问的基于文件的锁。相反，就基于文件的锁授权了读取访 问来说，基于文件的锁还授权读-写访问。

在本发明的实施例中，基于文件的锁包括覆盖全部资源的第一 组和覆盖部分资源(例如，资源的字节段)的第二组。图7是示出 根据本发明实施例的各种基于文件的锁及其兼容性的表。图7中示 出的各种基于文件的锁中的每一个都将在下面进行简要地描述。

字节-读-写基于文件的锁是对于部分资源的锁。字节-读-写基于 文件的锁可用于授权对资源上的字节段的读和写访问。

字节-写基于文件的锁是对于部分资源的锁。字节-写基于文件 的锁可用于授权对资源上字节段的写访问。

拒绝-读基于文件的锁是对于全部资源的锁。拒绝-读基于文件 的锁可用于拒绝除授权的拒绝-读锁之外的任何请求者对资源的读 访问。

拒绝-写基于文件的锁是对于全部资源的锁。拒绝-写基于文件 的锁可用于拒绝除授权的拒绝-写锁之外的任何请求者对资源的写 访问。

基于文件的锁与共享锁或排他锁(例如WebDAV锁)不兼容。 图7描述了各种基于文件的锁的兼容性。当特定的基于文件的锁与 先前授权的另一锁不兼容时，基于文件的锁将不被授权。因此，如 果字节-读-写锁和字节-写锁的范围不相抵触，则可对已具有在其上 授权的字节-写锁的资源授权字节-读-写锁。然而，不能在已具有在 其上授权的字节-写锁的资源上授权拒绝-读锁。

实际应用簇中的基于文件的锁

例如，可使用Oracle公司的RAC10g选项，在实际应用簇 (RAC)中实现数据库122。在RAC环境中，当对资源授权基于文 件的锁时，数据必须被存储在描述哪个数据库服务器对资源授权基 于文件的锁的数据库124中。

例如，存储在数据库中的资源可与(a)表示已对资源授权基 于文件的锁的标志以及(b)识别对资源授权基于文件的锁的数据 库服务器的信息相关。查找机构212将关于授权的基于文件的锁的 数据保持在存储器中。如果关于授权的基于文件的锁的信息对于 RAC实例中的其它节点可见，则存储在存储器中的信息必须永久地 被存储或以保存数据一致性的方式传送到RAC的其它节点。如果 存储在查找机构212中的信息对于除RAC存在的数据库服务器之 外的RAC的其它数据库服务器不可见，则由第一数据库服务器授 权的任何基于文件的锁可与第二数据库服务器的基于文件的锁相 抵触。

由数据库服务器122使用的上述基于文件的锁使数据库服务器 122处理对于由数据库124保存的文件的有状态请求，例如，请求 的NFS操作。因此，由于数据库122可使用上述的文件系统操作锁， 所以客户端110可以阻止数据一致性的方式使用NFS协议访问存储 在数据库124中的文件。

实现机构

可在根据本发明实施例的计算机系统上实现客户端110、数据 库服务器122、和数据库124。图8是示出了可在其上实现本发明 实施例的计算机系统800的框图。计算机系统800包括总线802或 用于传输信息的其它通信机构，以及用于处理信息的与总线802连 接的处理器804。计算机系统800还包括主存储器806(例如，随 机存取存储器(RAM)或其它动态存储装置)，连接至总线802， 用于存储信息和由处理器804执行的指令。主存储器806还可用于 在由处理器804执行指令期间存储临时变量或其它中间信息。计算 机系统800还包括连接至总线802的只读存储器(ROM)808或其 它静态存储装置，用于存储静态信息或用于存储器804的指令。设 置诸如磁盘或光盘的存储装置810，并将其连接至用于存储信息和 指令的总线802。

计算机系统800可经由总线802连接至用于向计算机用户显示 信息的显示器812，例如，阴极射线管(CRT)。包括字母数字和其 它键的输入装置814连接至总线802，用于将信息和命令选择传输 到处理器804。另一种类型的用户输入装置是诸如鼠标、跟踪球、 或光标方向键的光标控制器816，用于将方向信息和命令选择传输 到处理器804，并用于控制光标在显示器812上的移动。该输入装 置通常具有在第一轴(例如，x)和第二轴(例如，y)的两个轴上 的两个自由度，这使装置指定平面内的位置。

本发明涉及使用实施本文所述技术的计算机系统800。根据本 发明的一个实施例，响应于执行包含在主存储器806中的一个或多 个指令的一个或多个序列的处理器804，通过计算机系统800执行 这些技术。这些指令可从诸如存储装置810的另一机器可读介质读 入主存储器806。执行包含在主存储器806中的指令序列使得处理 器804执行本文中描述的处理步骤。在可选实施例中，可以用硬连 线电路代替软件指令或与软件指令相结合以实施本发明。因此，本 发明的实施例不限于硬件电路和软件的任何具体组合。

本文使用的术语“机器可读介质”指的是参与提供使机器以具 体方式操作的数据的任何介质。在使用计算机系统800实施的一个 实施例中，例如，各种机器可读介质参与将指令提供给处理器804 用于执行。这种介质可采用多种形式，包括但不限于非易失性介质、 易失性介质、和传输介质。例如，非易失性介质包括诸如存储装置 810的光盘或磁盘。易失性介质包括诸如主存储器806的动态存储 器。传输介质包括同轴线缆、铜线和光纤，包括构成总线802的导 线。传输介质还可采用声波或光波的形式，诸如在无线电波和红外 数据通信中生成的那些波。

例如，机器可读介质的通常形式包括软盘、柔性盘、硬盘、磁 带、或其它磁性介质、CD-ROM、DVD、或任何其它光介质、穿孔 卡、纸带、任何其它具有孔式样的物理介质、RAM、PROM、EPROM、 FLASH-EPROM、任何其它存储芯片或盒式磁带、下文中描述的载 波，或计算机可读取的任何其它介质。

各种形式的机器可读介质可参与将一个或多个指令的一个或 多个序列传送到处理器804用于执行。例如，指令可最初承载在远 程计算机的磁盘上。该远程计算机可将指令加载进其动态存储器并 使用调制解调器通过电话线发送这些指令。计算机系统800的本地 调制解调器可接收电话线上的数据并使用红外发射器将数据转换 为红外信号。红外探测器可接收红外信号中携带的数据，并且适当 的电路可将数据放到总线802上。总线802将数据传送到主存储器 806，处理器804从主存储器806中取得并执行指令。由主存储器 806接收的指令可在处理器804执行之前或之后可选地存储在存储 装置810上。

计算机系统800还包括连接到总线802的通信接口818。连接 到与本地网822相连的网络链路820的通信接口818提供双路数据 通信。例如，通信接口818可以是综合服务数字网络(ISDN)卡或 调制解调器，用于提供到相应类型的电话线的数据通信连接。作为 另一个实例，通信接口818可以是局域网(LAN)卡，用于提供到 兼容LAN的数据通信连接。还可实施无线链接。在任何这样的实 施中，通信接口818发送和接收承载表示各种类型信息的数字数据 流的电信号、电磁信号或光信号。

网络链路820一般通过一个或多个网络向其它数据装置提供数 据通信。例如，网络链路820可通过本地网822提供到主机824或 者由互联网服务商(ISP)826操作的数据设备的连接。ISP826又 通过现在通常称作“互联网”828的全球分组数据通信网络提供数 据通信服务。本地网络822和互联网828都使用携带数字数据流的 电信号、电磁信号或光信号。通过各种网络的信号和在网路链路820 上并通过通信接口818的信号(其将数字数据传送到计算机系统800 和从计算机系统800传送数字数据的信号)是传输信息的载波的示 例性形式。

计算机系统800可通过网络、网络链路820、和通信接口818 发送消息和接收数据(包括程序代码)。在互联网实例中，服务器 830可通过互联网828、ISP826、本地网822、和通信接口818传输 用于应用程序的请求代码。

当代码被接收到时，所接收的代码可被处理器804执行、和/ 或存储在存储装置810或其它非易失性存储装置中用于以后执行。 这样，计算机系统800可获得载波形式的应用程序代码。

在上述说明书中，参照许多因不同实施而不同的具体细节描述 了本发明的实施例。因此，本发明以及申请人所期望的本发明的唯 一和专有的标志，是以公布的权利要求的特定形式从该申请所公布 的一组权利要求，包括任何后续的修改。对于包含在这样的权利要 求中的术语，在此清楚阐述的任何定义都将限定权利要求中所使用 的这种术语的含意。因此，在权利要求中没有明确地提到的限定特 征、元件、特性、特征、优点或属性不应当以任何方式限制这种权 利要求的范围。因此，说明书和附图应当看作说明性的而不是限制 性的。