Techniques for increasing efficiency while servicing requests for database services

Techniques for servicing requests for database services include maintaining at a database server an available set of one or more database session data structures. Each database session data structure holds information to support one session of one or more requests for database services over a communication connection that persists for one or more communications from one client. A database session data structure in the available set is not associated with any client currently connected to the database server. These techniques allow a database server to more efficiently service more numerous requests for database services, such as generated by communications using a stateless protocol like HTTP.

FIELD OF THE INVENTION

The present invention relates to servicing requests for database services, and in particular, to efficiently servicing multiple short-lived requests, such as delivered by stateless hypertext transfer protocol (HTTP) messages.

BACKGROUND OF THE INVENTION

The client-server model of computer process interaction is widely used. According to the client-server model, a client process sends a message including a request to a server process, and the server process responds by providing a service. The server process may also return a message with a response to the client process. Often the client process and server process execute on different computer devices, called hosts, and communicate via a network using one or more protocols for network communications. The term “server” is conventionally used to refer to the process that provides the service or the host computer on which the process operates; similarly, the term “client” is conventionally used to refer to the process that makes the request or the host computer on which the process operates. As used herein, the terms “client” and “server” refer to the processes, rather than the host computers, unless otherwise clear from the context.

A database server provides database services in response to requests from a database client. For example, the database server writes data received in the request into one or more data containers in a particular database managed by the database server; or, the database server retrieves data from one or more of those containers that satisfy conditions specified in the request; or, it does both. In many circumstances the database client is a mid-tier application, distinct from the database server, which performs other services, such as accounting services, for one or more application users. The application itself may be configured for client-server operations, so that application users operate application clients that make application requests to an application server.

When a database client sends a request to a database server, the database server establishes a database session object to hold information related to providing database services to that client. The session object is a data structure that stores information that supports a session. A session is a related series of one or more requests for services made over a communication channel. The channel is typically established by the operating system of the host for the database server and that persists for one or more communications from the client, depending on the communications protocol used by the client.

The session information stored in the database session object may include any information well-known in the art. The session information may also include security information, such as identities of clients and users associated with a request, and access privileges associated with those users. The database session object may also contain references to the database and database schema associated with the request and the amount and location of memory areas on the database server host where processes and data associated with the session are cached.

As database servers are extended to support more options and communication protocols and security protocols, the amount of information stored in a database session object is increased. For example, to support database requests for hierarchical data, such as files and folders of a file system stored in a repository within the database, the database session object is extended to include information about a root container for the hierarchy and a document that contains configuration information about the hierarchy, such as an XML schema document. To associate users or files with attributes of those users or files, hash tables are often used; in such circumstances the database session object may include the hash tables.

As a result of the many important pieces of information stored in a database session object, a significant amount of database server and server host resources are consumed in generating the database session object. Consumption of central processing unit (CPU) processing cycles are especially significant, leading to a perceived increase in response time needed for the database to return a result. When a client ends its communication session with the database server, the associated database server object is deleted and resources assigned to the database session object are released.

While suitable for many purposes, establishing a new database session object for every user who causes requests for database services does suffer some disadvantages. For example, when there are many database users who connect to and disconnect from the database frequently, the resources consumed by the database server to establish and release database session objects can noticeably increase database server response time and therefore decrease database server performance.

To improve response time, some mid-tier applications establish a pool of connections with a database server. The connections in the pool are maintained and reused by the application as different application users join and exit the application. On the database server, relatively few database session objects are established. Those that are established are associated with the application for the long-lived connections in the pool. Each time a different user is associated by the application with one of the connections in the pool, the application sends some data to the database server that causes a new session to be created.

While suitable for many purposes, there are some disadvantages to relying on mid-tier applications to re-use a pool of long-lived connections to the database server. One disadvantage is that the mid-tier application must be developed to establish and maintain the pool of connections. This increases the cost of developing and testing mid-tier applications that use the database server.

Another disadvantage is that an excess of database session objects may be generated because, while each application establishes a pool for its optimal number of users, it is unlikely that all applications will need to support their optimal number of users at the same time. For example, five mid-tier applications each expect a optimal number of ten (10) and therefore each establishes a pool of ten (10) database connections. As a result, 50 database session objects are generated on the database server. At any one time, some of those applications have fewer than ten users; for example, four (4) applications may have four (4) users when one has nine (14) users—for a total of 30 users. While the number of users at each application varies, the number of used connections to the database actually varies only slightly around 30. Therefore 50 database session objects are established to serve 30 used connections. The database server resources consumed to maintain the 20 excess database session objects wastes valuable resources on the database server host. The application resources consumed to maintain the 20 excess connections wastes valuable resources on the hosts of the applications.

Another disadvantage of other approaches is an escalating reliance by database users on hypertext transfer protocol (HTTP) requests for database services. HTTP requests for database services are popular because a user with a common client (called a “web browser,” or, simply, “browser,”) can then request database services over the Internet even without a mid-tier application. In addition, HTTP has been extended by a protocol called web-based distributed authoring and versioning (“WebDAV”) to support hierarchical operations over the internet that mimic popular file systems. However HTTP and WebDAV are stateless protocols that do not form communications channels that persist beyond a few messages. Thus, each few messages from a web browser containing requests for database services involve the creation and subsequent release of a database session object by the database server. A single user may generate dozens of messages at one sitting which involve several database connections. The repeated creation and release of database session objects consumes valuable database server resources. Such HTTP-based requests are expected to proliferate over the next few years, further taxing database server resources and degrading database server performance.

Based on the foregoing there is a clear need for techniques that service requests for database services that do not suffer the disadvantages of the above approaches and that do not degrade database server performance.

The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not to be considered prior art to the claims in this application merely due to the presence of these approaches in this background section.

DETAILED DESCRIPTION OF THE INVENTION

Techniques for servicing requests for database services include maintaining at a database server an available set of one or more database session data structures. Each database session data structure holds information to support one session of one or more requests for database services over a communication connection that persists for one or more communications from one client. However, a database session data structure in the available set is not associated with any client currently connected to the database server.

The techniques described hereafter allow a database server to more efficiently service more requests for database services, including database service requests generated by communications using a stateless protocol like HTTP.

Structural Overview

FIG. 1is a block diagram that illustrates a system100for handling numerous connections with clients for database services, according to an embodiment. The system includes a database server110connected to a network104. On or more database clients102are also connected to network104. In the illustrated embodiment, three clients,102a,102b,102care connected to network104. In other embodiments more or fewer clients102are connected to network104.

The database clients102communicate with database server110using one or more communications protocols, such as open protocols HTTP and WebDAV and proprietary protocols provided by an enterprise that provides the database server and clients. In the illustrated embodiment the three database clients102a,102b,102ccommunicate with the database server110through network104. In some embodiments, one or more of clients102reside on the same host computer as server110, so that such clients can communicate with the server110directly, without using the network104.

The database server110includes memory120on the database server host computer, which is allocated for use by the database server110. The database server110maintains several data structures in memory120. Among the data structures maintained in memory120are zero or more session objects122, one or more process state objects130a,130b, collectively referenced hereinafter as process state objects130, and a session pool object140. In object-oriented technologies, an object is a data structure that stores data that indicates one or more attributes or methods or both. An object is one instance of an object type that is defined in one or more object type data structures. In other embodiments, the data structures that are illustrated as objects inFIG. 1need not be objects according to object-oriented technologies.

When a client connects with database server110, a communication process on the server host handles the communications. In the illustrated embodiment, the communication process passes the database request to a database server communications process. A process state object130in the memory120is created when the database server communication process is created, and is associated with the database server communication process. The process state object130holds data indicating a connection with a client and methods for sending messages to and receiving messages from the client. The process state object includes data that associates each connection with a session object122. In some embodiments, the host communication process and the database communication server are the same.

In the illustrated embodiment, session objects122include session objects122a,122b,122cand zero or more additional session objects indicated by ellipsis123. Data or methods, or both, relevant for each connection to a client are stored in the associated session object122.

For example, in some embodiments, each session object122includes four types of information—types I, II, III, IV. Type I information is user information that indicates a user of the associated connection, the user's roles, and the user's privileges, among other information about the user. Type II information is current transaction information that indicates the current database command, such as the current structured query language (SQL) statement, of a set of commands that constitute a database transaction, and indicates other information about the database transaction requested.

Type III information is cached information that is moved into the session object from persistent storage for improved performance because the information is used frequently during a session. Examples of cached information include hash tables that contain access control lists (ACLs), and database configuration information used for documents stored hierarchically in the database. Hash tables are used to access information about a named item, given the name of the item. An ACL is used to associate a set of privileges with each user for all authorized users. Database configuration information is used, for example, to associate default properties of files and folders stored in the database with the names and file extensions of those files and folders.

Type IV information includes Pins for objects in shared memory A Pin is some information associated with an object to indicate that a session is currently using the object. The database server moves some database objects from persistent storage to a shared portion of memory where those objects are accessible by several processes, including processes associated with several different sessions. The Pins indicate the database objects in shared memory to which the session has access. The Pin indicates that the object should not be purged from the shared memory. The database objects include cursors, database schema objects, and XML schemas, among others. A Cursor is an area in shared memory where a parsed SQL statement and information for processing that statement are kept. Database schema objects refer to database objects that belong to a particular user, such as tables, views, and stored procedures. An XML schema is a data model for XML documents of a certain type. The XML schema contains information about the types of the elements, the attributes of each type, and the hierarchical relationships among elements in XML documents of that type.

According to the illustrated embodiments, the system100also includes the session pool object140. The session pool object140includes data that indicates zero or more available session objects122that are not associated with any client currently connected to the database server. The data that indicates an available session object is represented inFIG. 1, for an example embodiment, by an arrow pointing from session pool object140to session object122b. The session objects122, indicated by the session pool object140, are not among session objects122associated with a currently connected client by a process state object130. The data that indicates a session object associated with a currently connected client in a process state object130is represented inFIG. 1, for an example embodiment, by arrows pointing from process state objects130a,130bto session objects122a,122c, respectively.

Functional Overview

According to the illustrated embodiments, session objects are not deleted when a connection ends; but, instead, are saved as available session objects and reused with new connections. In the illustrated embodiment, the session pool object140indicates the available session objects.

By retaining available session objects122indicated by the session pool object140in memory120, the resources that would be consumed to delete and recreate the session object122when connections are ended and started, respectively, are conserved. When a new client connects to the database server110and is associated with an extant session object122, only the type I and type II information is typically updated. The type III and type IV information already in the session object is often retained unchanged. Therefore, the resources that would be consumed to generate the type III and type IV information are also conserved. The saved resources become substantial when clients request database services in multiple short-lived connections.

Maintaining a session pool on the database server is also an advantage when many applications use the same database server. The applications need not consume resources to maintain their own pools and the database server need not consume resources to maintain the pool of connections with all those applications. In addition, the total number of session objects to support the maximum number of simultaneous users of the database is often less than the total number of session objects to support the maximum number of simultaneous users on each application separately, because it is unlikely that all applications experience their maximum number of users at the same time.

Method for Servicing Requests with Available Session Objects

FIG. 2is a block diagram that illustrates, at a high level, a method200for maintaining a pool of available session objects to service requests for database services. Though steps are depicted inFIG. 2in a particular order, in other embodiments the steps may be performed in a different order, or overlapping in time.

In step210, a session pool object140is established, which indicates a set of available session objects, if any, which are not associated with a current connection to a client. In other embodiments, other methods of maintaining an available set of one or more database session objects are employed, during step210. For example, each session object may include an attribute that indicates its availability. The attribute may be used to indicate a client or connection with which the session object is associated. The attribute may then contain a null value when the session object is not associated with any client or connection. A null value for this attribute therefore indicates that the session object is available.

In some embodiments, the session pool object140includes a first attribute that contains a value indicating a number of session objects that are available and a second attribute that indicates a list of the session objects that are available. The data that indicates each session object in the list may be one or more properties of the session object. In one embodiment, the data that indicates each session object is the name of the session object. In another embodiment, the data that indicates each session object is an address of the first byte of the session object in memory120.

In some embodiments, step210is performed automatically when an instance of the database server is started. In some embodiments, step210is performed in response to a command issued manually by a database administrator or by an application. In some embodiments, the session pool object140is created when the first session object122is released, as described below with reference to step264.

In some embodiments, step210includes creating a set of one or more available session objects122and storing the number and list of the newly created session objects122in the session pool object140when the session pool object140is created. In some embodiments, no available session objects122are created when the session pool object140is created, so that the number of available session objects is initially zero and the list is initially empty.

In step220, a request is received from a client that starts a session. For example, a request is received from database client102afor database services. The database server determines whether a session has already been created for this client by checking the contents of process state object130. If a session is already created for this client, a session object122associated with the client is indicated in the process state object130; and that session object122is used. If the process state object130does not contain data indicating this client102a, then a new session starts, and control passes to the next steps in the method which associate a session object122with the client102ain process state object130. In many embodiments, if the request from client102ais delivered using HTTP or WebDAV, then process state object130does not contain data indicating this client102a, and a new session starts. When a request is received from a client that starts a session, control passes to step230.

In step230, it is determined whether there are any available session objects that are not associated with a connected client. For example, the session pool object140is accessed to determine if the number of available session objects is greater than zero. If not, control passes to step232to create a new session object. If there is a set of one or more available session objects, then control passes to step234to select one.

In step234, one of the available session objects in the set is selected for use with the client102a. For example session object122bis selected. In the illustrated embodiment, the selected session object is removed from the set by deleting the list element indicating the selected session from the session pool object140, and by decrementing the number of available session objects in the session pool object140.

In step232, a new session object is created. Any method known in the art for creating the new session object may be used. For example, space in memory120is allocated for session object122cand information for types I, II, III and IV, appropriate for client102a, is generated and stored in session object122c.

In step240, the session object for the client is associated with the client. For example, the session object122b, selected from the session pool object140during step234, is associated with the client102ain the process state object130. In an alternate example, the session object122c, created during step232, is associated with the client102ain the process state object130. During step240, type I and type II information is generated, if necessary, to refresh and replace that information already in the session object, if any.

In step250, the session with this client terminates. Under some protocols, termination occurs after the database server has performed one or more database operations based on one or more requests beginning with the request received in step220, and then the database server either receives an explicit request from the client102ato terminate the connection, or an elapsed time since the last request was received has exceed a time-out threshold. Under some protocols, such as HTTP version 1.0, termination occurs after the database server has performed one or more database operations based on the request received in step220. In some embodiments, all data in process state object130related to the terminating client is deleted during step250.

In step260, it is determined whether the set of available session objects is full. In some embodiments, there is no limit placed on the number of available session objects that can be retained in memory, so the set is never full. The set will eventually grow to a number of session objects that is less than or equal to the greatest number of sessions simultaneously supported by database server110. However, in some embodiments, a maximum allowable limit on available session objects is set to prevent the database server from devoting too many resources to retain session objects that are not in use. Once the number, or size, of session objects122that are available reaches or exceeds this maximum allowable limit, the set of available session objects is considered full. In some embodiments, step260is performed by accessing the data in session pool object140to determine the number or size of the available session objects. In embodiments in which the session pool object140is absent, the set of available session objects is considered not full. In some embodiments, the session pool object140is absent until the first session object is released, as described below with reference to step264.

If it is determined in step260that the set of available session objects is full, then control passes to step262. In step262, the session object associated with the terminating client102ain process state object130is deleted. For example, session object122cassociated with client102ain process state object130is deleted. In some embodiments, all data in process state object130related to the terminating client is also deleted during step262.

If it is determined in step260that the set of available session objects is not full, then control passes to step264. In step264, the session object associated with the terminating client102ain process state object130is added to the set of available session objects. For example, session object122cassociated with client102ain process state object130is added to the list of available session objects and the number of available session objects is incremented. In some embodiments, all data in process state object130related to the terminating client is also deleted during step264.

In some embodiments, the session pool object140may be absent until the first session object122is released. In these embodiments, step264includes a step to determine whether the session pool object140exists in memory120. If the session pool object140does not exist, then it is created during step264. At creation during step264, the number of available session objects is set to one, and the list of session objects includes data indicating the session object of the terminating client. For example the list of session objects includes data indicating session object122c.

Using these steps, a pool of session objects is maintained on the database server, which reduces the resources consumed to create and delete session objects for multiple short-lived connections to database clients.

Example Use of Method

To further illustrate the operation of the techniques presented here, it is assumed that three clients102a,102b,102ccommunicate with database server110using HTTP to request database services. It is further assumed, for purposes of illustration, that the current instance of database server110has recently started and that no session objects122have yet been created in memory120. It is further assumed, for purposes of illustration, that process state object130has been created but that it contains no data indicating any client or connection, and that session pool object140has been created and contains data indicating a number of available session objects is zero and the list of available session objects is empty.

When an HTTP1.0 request for database services is received from database client102a, a new session is started as in step220. In step230, it is determined by accessing the session pool object140that there are no available session objects. Control passes to step232and session object122ais created. Data indicating session object122ain association with client102ais added to process state object130.

Before the connection with client102ais closed, HTTP requests for database services are received from database client102band then102c, starting two new sessions. In step230, it is determined by accessing the session pool object140that there are no available session objects, for both new sessions. Control passes to step232for both sessions, and session objects122band122care created. Data indicating session object122bin association with client102b, and session object122cin association with client102c, are added to process state object130.

It is assumed, for purposes of illustration, that the server110completes the services requested by client102bbefore completing the services requested by clients102aor102c. Since the request was sent under HTTP 1.0, completing the services terminates the connection. In step250, the session with client102bis terminated. The session pool object140still indicates no available session objects, so it is determined in step260that the set is not full. Control passes to step264. In step264, the session object122bis added to the list and the number of available session objects is incremented to 1. Data indicating client102bis deleted from process state object130. At this moment in time, the session objects indicated by the process state object130and the session pool object140are as indicated by the arrows emanating from objects130,140inFIG. 1.

It is further assumed, for purposes of illustration, that client102binitiates another HTTP 1.0 request for database services before the database server110completes the services being performed for clients102aand102c. In step220, the request from client102bis received at server110. Because this is a new connection, this request initiates a new session. Control passes to step230.

In step230, data indicating one available session object is found in session pool object140, so control passes to step234. In step234, the only available session object, session object122b, is selected from the list of available session objects in session pool object140. Session object122bis removed from the list; and the number of available session objects is decremented to zero. In step240, session object122bis associated with client102bin process state object130. The type III and type IV information is reused that is already in the session object122b. Because the same client has been associated with session object122bas the last time session object122bwas used, the type I information in the session object can be reused also, in whole or in part.

As shown by this example, session object122bis not deleted and recreated just because the client102bassociated with the session object122bhas terminated its connection. Consequently, substantial resources are saved that would have been consumed in deleting and reconstructing the session object122b.

Hardware Overview

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor304for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device310. Volatile media includes dynamic memory, such as main memory306. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus302. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

The received code may be executed by processor304as it is received, and/or stored in storage device310, or other non-volatile storage for later execution. In this manner, computer system300may obtain application code in the form of a carrier wave.