Patent Application
20100036957
The invention is directed to an approach for implementing a transfer of a network session for database sessions.
A network session is the establishment of a communications channel from one location to another on a network. Network sessions are used for many purposes in the computing world. For example, a network session can be used to establish a database session.
A database session/connection is a heavyweight resource that corresponds to state on the database, e.g., for purposes of authentication, processing SQL statements, and other reasons for maintaining information about users or connections. It is typically considered very expensive in terms of computing resources to create and tear down a database session.
In addition to the computing costs to create and maintain a database connection, there is also an “opportunity cost” when assigning a database connection to a user or client (hereinafter collectively referred to as either “user” or “client”). This is because most computing/database platforms have a realistic limit on the number of simultaneous connections that can be created and assigned to users. As a result, if the limit of database connections has already been allocated to a first set of users, this may block another user from being able to establish a connection. This is particularly costly if the users that hold the connections are in a waiting or idle state, while there are other users that are ready to provide work but are prevented from doing so because the connections already being held by the idle user(s).
Therefore, it is often desirable to allow multiple users to share a session or connection. For example, consider when there are two users that are assigned to the same session or connection. It is highly unlikely that both users would consistently need to be actively using the session or connection. This is because the users would likely have numerous periods of waiting or idleness, e.g., while waiting for data, inputs, or processing. There, one approach for connection sharing is to statically assign multiple users to the same session or connection.
A more advanced form of sharing is to provide “pooling” of connections or sessions. Instead of statically assigning users to specific connections or sessions, a pool of connections or sessions is maintained, where each free session or free connection in the pool would be available to any user that is seeking a session or connection. Once the user has stopped using the session or connection, then that resource is released and allowed to be acquired by another user.
The present invention is directed to an improved approach for sharing resources such as sessions and connections in database systems. According to some embodiments, conduits and shared memory are employed to facilitate the transfer of network sessions. This provides a very efficient way to share processing entities across multiple users or clients. Other and additional objects, features, and advantages of the invention are described in the detailed description, figures, and claims.
The present approach is directed to a method, system, and computer readable medium for performing efficient bi-directional transfer of network sessions. Conduits and shared memory are employed to facilitate the transfer of network sessions. This provides a very efficient way to share processing entities across multiple users or clients.
For the purposes of illustration, embodiments of the present invention will be described with respect to the n-tiered computing architecture. It is noted however, that the present invention can be employed in any suitable computing architecture, such as the classic client-server architecture, and is therefore not to be limited to its use in the n-tiered architecture unless specifically claimed as such.
While embodiments of the present invention are directed to server-side connection pooling, it is noted that the middle tier server 104 can also be used to implement connection pooling so that multiple middle tier processing entities, such as threads, processes, or tasks, (hereinafter categorically referred to by example as “processes”) can share already opened connections and serially reuse them without having to create and tear down one for each client request.
Server side pooling may take place at database server 106 to handle resources such as sessions and threads of execution. For purposes of server side pooling in an n-tiered system 100, the direct “client” of the server process would be an entity at the middle tier server 104. By contrast, in a classic client-server architecture, the direct “client” of the server process could be the end-user client node 102a or 102b.
When a client side process needs a resource, it issues a request to the database server 106. This results in assignment of a dedicated resource from the pool to the client. The client then does the required work on the dedicated resource, and upon completion of the work or a period of inactivity, the resource is released back to the pool. At this point, a completely different client process on potentially a different client machine can reuse the same pooled resource. A suitable approach for implementing server-side pooling is described in co-pending U.S. application Ser. No. 12/047,278, filed on Mar. 12, 2008, which claims priority to Provisional Application No. 60/906,941, filed on Mar. 13, 2007, which are hereby incorporated by reference in their entirety.
Some embodiments of the present invention utilize a broker-worker architecture to implement connection pooling. This architecture is shown in
The broker 206 is responsible for receiving initial incoming work requests 210 from clients. Once a free server process in the server pool 204 has been identified, then a hand-off occurs to transfer responsibility for servicing the work request 210 to the free server process. Therefore, to support extreme scalability with a multi-process server model, network sessions can be managed and handled efficiently between multiple processes. It is the process for performing this transfer of responsibility that is the subject of some embodiments of the invention.
For example, for a UNIX-based system, the client establishes a connection to the server/broker by causing the creation of a socket descriptor to represent a network connection end-point. The socket descriptor is an operating system mechanism that essentially creates a bi-directional file descriptor for reading from and writing to a communications channel between two points, i.e., between the server and the client.
In addition to the socket descriptor used by an operating system, application-specific parameters and settings may need to be established or identified. For example, for a database application, the database network session may comprise connection specific state such as negotiated session options, session and service request details, user-level authentication, permissions, and profiles.
At 304, the broker identifies an available server process from within the server-side pool to handle the client work requests. Any suitable data structure can be employed within the server to maintain a list of free server processes. After the server process has been allocated to the client, the server process would then be removed from the list of available processes for the server pool.
A forward hand-off is then performed, at 306, to transfer the network session from the broker to the server process. The specific details of the forward hand-off according to one embodiment are provided below with respect to the description of
According to some embodiments, once hand-off has occurred, the broker is no longer actively communicating with the client. Instead, the client will directly communicate with the server process. This provides enormous performance improvements and facilitates high levels of scalability, since the broker is taken out of the direct communications chain between clients and server processes, thereby removing a significant bottleneck for communications.
At 308, the server process performs the requested work on behalf of the client. This continues until there is a determination made at 310 that no further work is to be immediately performed. This may occur, for example, if the client has no further work at all or if there is an idle period of no new work requests, where the idle period exceeds a designated threshold.
A reverse hand-off is performed, at 312, to transfer the network session from the server process back to the broker. The specific details of the reverse hand-off according to one embodiment are provided below with respect to the description of
Reference is now made to
The server process will also receive the application-specific parameters and settings for the client, such as negotiated session options, session and service request details, user-level authentication, permissions, and profiles. According to some embodiments, a template-based approach is used to transfer this information. A named template representing these session characteristics is created and stored into the shared memory, and is accessible to all server processes. This approach, at 406, allows the broker to just send the template name or a pointer to the template in shared memory, rather than transferring the details of that information using IPC calls, thereby saving on the transfer costs for the network session state. With the template name or pointer, the server process can perform direct memory access to obtain that application-specific information.
Therefore, this generally allows all future network sessions to be clubbed into a template based on client tagging, or based on session characteristic comparison. The template approach also provides efficiencies based on the fact that most database connection requests originate from a few middle-tier clients. These client requests are typically identical, with similar network negotiated session options and characteristics.
Once hand-off has occurred, then at 410, the communications link between the client and broker will be suspended. It is noted that the broker does not completely remove its references to the network session, e.g., it will maintain the connection and session information along with session state information. The broker process will continue to maintain a reference to the socket descriptor for the client network session. Therefore, the link is merely “suspended” rather than being deleted since the broker still has access to the socket descriptor, but will avoid actively listening or writing data to the socket descriptor. In effect, the broker process ensures that the socket descriptor is dormant so that no activity will be initiated on it until it is received back through a reverse hand-off, as described in more detail below.
Once the hand-off has occurred, then at 412, the server process will directly communicate with the client. Since the server process will be directly accessing the socket descriptor, this means that no communications between the server and the client will need to be transferred through the broker.
Referring to
Next, as shown in
The items of connection or session information needed for the forward hand-off are passed from the broker 506.to the server process 502c via the conduit 544 as an IPC message. For instance, information regarding the socket descriptor 542 is passed to the server process 502c through the conduit 544. In addition, the name or address of the template 536 is also passed to the server process 502c via the conduit 544.
Once the server process 502c has sufficient data to complete the hand-off, then as shown in
The broker 506 will also suspend its communications with the client 530. It is noted that the broker 506 is merely suspending its communications with client 530, rather than completely severing the communications link. This is accomplished by the broker maintaining its session and/or connection information for the client 530, e.g., including maintaining its reference to the socket descriptor 542.
Thereafter, as shown in
The reverse hand-off is performed to transfer the network session from the server process back to the broker. At 602, the server process communicates with the broker to inform the broker of the handback. Given that the broker process still has all the session state for the client (including the socket descriptor), this process is extremely efficient. The server process only needs to indicate which network session it is handling back. No other transfer takes place according to this embodiment.
At 604, the server process then terminates its communications link to the client. This is accomplished by removing the session state; including the socket descriptor information, from the server process. The server process is then placed back on the list of free processes and is available to be selected to service another client.
After the hand-off, at 606, the broker resumes monitoring of the network session for the client for further activity. When activity/requests are detected on the session, the broker repeats the process of finding an idle/free server.
As shown in
Therefore, what has been described is a very advanced and efficient approach for effecting transfers of network sessions to implement connection pooling. The forward handoff is extremely optimized due to a variety of factors, including the use of a template in shared memory to reduce communications requirements for the hand-off. In the reverse direction, the maintenance of session state at the broker also optimizes and increases the efficiency of the handback.
Efficient bi-directional session transfers can be therefore be used to implement highly scalable servers. Its use with server side connection pooling allows the database to handle an order of magnitude more client requests with the same hardware.
Past solutions that deal with this scalability issue have not been efficient as most approaches involve session or connection pooling on the client-side, whereas the server side still has to maintain a session for each client connection
According to one embodiment of the invention, computer system 1400 performs specific operations by processor 1407 executing one or more sequences of one or more instructions contained in system memory 1408. Such instructions may be read into system memory 1408 from another computer readable/usable medium, such as static storage device 1409 or disk drive 1410. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and/or software. In one embodiment, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the invention.
The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to processor 1407 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 1410. Volatile media includes dynamic memory, such as system memory 1408.
Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
In an embodiment of the invention, execution of the sequences of instructions to practice the invention is performed by a single computer system 1400. According to other embodiments of the invention, two or more computer systems 1400 coupled by communication link 1415 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions required to practice the invention in coordination with one another.
Computer system 1400 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 1415 and communication interface 1414. Received program code may be executed by processor 1407 as it is received, and/or stored in disk drive 1410, or other non-volatile storage for later execution.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.
