Accessing network databases

[0002] This invention relates generally to accessing relational databases on networks to provide cached information to a client browser.

[0003] Increasingly, data is cached on a server and accessed by clients over the Internet. This decreases the resource requirements on the client while providing ready access to the information with a sufficiently high speed Internet connection. Conventionally, when the client needs information (such as the address of a web site that has been bookmarked), the browser resident on the client formulates a request and transmits it over the Internet to a hypertext transfer protocol (HTTP) server. The server then transmits the request to a relational database management server over a common gateway interface (CGI) program. Each time the relational database management server is accessed, a new connection and a new session to that server must be established.

[0004] Referring to FIG. 3, the establishment of such a connection and a session is somewhat time consuming and needlessly bogs down the processing of the relational database management server. The request from the browser must be decoded as indicated in block 48. Then, a Structured Query Language (SQL) query must be parsed from other information such as the HTTP server's uniform resource locator (URL) (block 50). The relational database management server then must bind the program variables as indicated in block 52. The relational database management server executes the query as indicated in block,54. Thereafter, the relational database management server must fetch the results as indicated in block 56.

[0005] Generally, access by the browser is stateless. The term “stateless” refers to a process that participates in an activity without monitoring all the details of its state and particularly is not aware of the context of a given process. Because of the stateless character of the browser's request, it is difficult to maintain any type of caching mechanism on the server side.

[0006] Therefore, there is a need for a more efficient way to handle stateless accesses to a relational database management server from an Internet browser.

[0007] FIG. 1 is a schematic depiction of one embodiment of the present invention;

[0008] FIG. 2 is a flow chart for software for implementing the embodiment shown in FIG. 1; and

[0009] FIG. 3 is a flow chart for accessing a relational database from an Internet browser in accordance with one embodiment of the present invention.

[0010] Referring to FIG. 1, a client 12 is a processor-based system with a connection to the Internet 14. The client 12 includes an Internet browser 13 having a software application that interfaces between the client 12 and the Internet 14. The client 12 may be a desk top computer or processor-based appliance such as a cellular telephone, as two examples.

[0011] In some embodiments of the present invention, the client 12 may cache a large amount of information on the relational database management server 20. This data caching frees the client 12 resources from being tied up by storing a large amount of data on the client 12. The client 12 may cache specific information such as a user profile, personal information manager (PIM) information such as a calendar or an electronic mail address book, and uniform resource locator (URL) bookmarks for commonly accessed Internet web sites.

[0012] When the user wishes to access such cached data, the browser 13 formulates a stateless request. The request is transmitted over the Internet 14 to a hypertext transfer protocol (HTTP) server 16 also known as a web server. The HTTP server 16 handles the request in a stateless fashion. The HTTP server 16 forwards the request over a common gateway interface (CGI) program 18 to relational database management server 20.

[0013] In the processor-based system 10, the request is transformed into a stateful request. A stateful request takes into account its content. In one embodiment of the present invention, an application server 22 acts as middleware between the HTTP server 16 and the relational database management server (RDBMS) 20. The application server 20 facilitates access to commonly utilized information by maintaining caches that contain connections and sessions 27 to access commonly requested information. When information is repeatedly requested, a cached SQL query session 26 may be stored in association with the application server 22. Such commonly requested information may be the subject of a persistent connection 28 between the relational database management server 20 and a relational database 30. Thus, a persistent connection 28 and an active session/connection association 27 may be maintained for accessing such information.

[0014] As a result, it is not necessary to undergo the extensive procedures shown in FIG. 3 for establishing a connection from the browser 13 to the relational database 30 for common, often repeated, database 30 queries. The application server 22 need only re-execute and fetch queries using its cached SQL query sessions 26 when those queries correspond to one of the commonly requested, cached SQL query sessions 26.

[0015] As a result, the application server 22 may reduce the expansive database opening overhead. It may also substantially reduce the overhead associated with SQL parsing, and variable bindings. For most query requests on behalf of multiple clients, the application server 20 need only re-execute and fetch the queries from its cached SQL query sessions 26. For less frequent queries, the application server 12 can choose to open a new connection 28 or a new session 24 to service the request. Depending on the frequencies of such requests and the load of other, more frequent queries, the application server 22 can prioritize the types of requests, choosing to give resources to other queries first. Thus, the application server 22 may have the flexibility and scalability to serve potentially large numbers of clients 12 during system configuration time as well as during run time.

[0016] When receiving a query through the CGI program 18, the application server 22 tries to find an existing session containing a reference to that query for execution. Under this architecture, the application server 22 caches the sessions associated with frequent queries and is therefore ready to execute upon request from a client 12. The sessions may be grouped to share a fixed number of database connections that are pre-opened. If the request traffic increases dramatically, the application server 22 can dynamically open more database connections and sessions to balance the extra load.

[0017] By creating and intelligently maintaining a pool of connections and sessions 26 for frequently repeated requests, high performance and optimized data access may be achieved in some embodiments of the present invention. At the same time, the system 10 satisfies the requirement of stateless data access by multiple clients 12 using hypertext transfer protocols. The application server 20 converts the stateless request from the HTTP server 16 into a stateful request for intelligently accessing the relationship database 30.

[0018] Turning next to FIG. 2, the database query software 32, in accordance with one embodiment of the present invention, begins by receiving an HTTP format request from a client 12 and forwarding that request over a common gateway interface program 18, as indicated in block 36. The application server 22 then receives the request as indicated in block 38. The application server 22 attempts to relate the current request to a pre-cached request responding to an already open connection from the relational database management server 20 to the database 30 (diamond 40).

[0019] If such a correlation can be established, for example because it is a request that is made frequently by any client 12, a persistent connection and session 27 may be utilized (block 44) to access the information from the relational database 30.

[0020] If the request is not one which is frequently made or which has not been the subject of a cached SQL query session 26, it is treated as an un-cached SQL query session 24. As a result, a new connection 28 must be established as indicated in block 42. The software 47 for completing the establishment of a new connection is shown in FIG. 3.

[0021] After the new connection is established (FIG. 3, block 56), a check at diamond 58 determines if the request is a frequent query. A count may be maintained for each request. When the count exceeds a predetermined number, for a given client 12, a persistent connection may be established as indicated in block 60. A cached SQL query session 26 is also established (block 62).

[0022] While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.