Patent Publication Number: US-6038562-A

Title: Interface to support state-dependent web applications accessing a relational database

Description:
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to accessing data in a database from a web browser on the internet, and more specifically to a system, method, and program for interfacing web applications, which parse requests from the web browser, to a database management system. 
     2. Description of the Related Art 
     The ubiquity of the internet&#39;s world wide web has opened up new dimensions for commerce. Previously, electronic transactions were exclusively used by highly sophisticated business enterprises, such as banks, that could afford to (or could not afford not to) use computer controlled communications. Today, the internet can provide the efficiency of electronic transactions among business enterprises and customers at significantly low costs for the medium to small business. The world wide web, and its successors, are viewed as a well accepted standard communications protocol. 
     The increasing role that the internet is playing in commercial transactions is spawning the development of new database management system applications that are at the heart of these commercial transactions. Data base management systems, the mainstay of book-keeping, for service sensitive transactions and the world wide web are today&#39;s foundations for service sensitive electronic transactions. 
     The requirements of web applications that access a database are different from that of conventional database applications. The &#34;all-or-nothing&#34; semantics of the flat transaction model supported by most commercial database systems is generally adequate for conventional applications. Web applications typically require selective recoverability, i.e., flexibility in deciding what should be committed to the database. Also, web applications can have transaction structures that require a combination of more than one transaction model, e.g. supporting flat, nested and chained transaction models in a transaction structure. A complex transaction structure is defined herein as any transaction structure or combination of transaction structures that includes at least one non-flat transaction structure. For example, see Jim Gray, Andreas Reuter, &#34;Transaction Processing: Concepts and Techniques,&#34; Morgan Kaufman Publishers, Inc., 1993, chapters 1 and 4. 
     As an example, consider a typical travel agency application that allows customers to plan a vacation trip. The customer is given access to the required databases of airline companies, home care and car rental agencies. The whole trip planning activity can be considered a top-level transaction and nested within it are lower-level transactions in the form of accesses to individual agency databases. 
     Assume that a customer wants to plan an itinerary from city A to city F going through cities B, C, D and E. Also, assume that the customer plans to be away from home whether or not the customer succeeds in finding the right reservations for the itinerary, and wants to request a home care agency to take care of the customer&#39;s home during the vacation period. The choice of cities in the itinerary depends on availability of airline and car rental reservations. 
     FIG. 1 shows a typical transaction structure. At any point (before making the final payment), the customer may chose to cancel the vacation, i.e., rollback all airline and car reservations requested on behalf of the customer. Alternatively, if a car reservation is not available at a city, the customer may chose to drop the city from the itinerary and make an alternate airline reservation. 
     For example, in FIG. 1, if the customer does not find a car rental reservation at city C, 111, the customer may drop the city from the itinerary and look for an alternate route. The subtransaction 112 in the home care agency database will not be rolled back since the customer intends to be away from home anyway. However, the ongoing subtransaction 113 in the airline database should remain active together with the subtransaction 114 in the car rental database to finalize the itinerary. 
     To summarize, the overall structure is that of a chained transaction with the subtransaction in the home care agency database forming one part of the chain. The second part of the chain has a nested structure consisting of subtransactions in the airline and car rental agency databases. Within the nested structure, the customer should be given the flexibility of canceling reservations and making new ones i.e., selective recoverability. 
     Conventional database applications will have application specific logic that is predetermined depending upon the transaction structure of the application. However, with web interfaces, the transaction structure of an application may not be pre-determined. It may be determined by the user by way of the sequence in which actions are requested at the database; and, more specifically, by the order in which hyper-links are selected for navigation. 
     To support applications similar to the one described above, state information about the application must be maintained. In the example above, state information includes details about the reservations made and what the customer owes to individual agencies. Hence these applications are &#34;state-dependent&#34;. 
     Web applications accessing a database have typically been supported using the Common Gateway Interface (CGI) standard. The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web Servers. A Web daemon will execute the CGI program to transmit information to the database engine and to receive the results back for display to the client. Briefly, when a user uses the web browser to access a file in a directory called the CGI-BIN, the file is executed and the results are returned to the web browser (instead of the file itself being returned to the browser). The CGI specifies interaction between a program and a web browser, not the interaction between the program and a database. For example, see &#34;Common Gateway Interface,&#34; and &#34;The Common Gateway Interface&#34; CGI-Common Gateway Interface, cgi@ncsa.uiuc.edu. 
     Every request to the CGI-BIN file causes the file to be executed and the results returned to the browser. Hence, the CGI-BIN file cannot maintain state information between successive invocations. However, the state information can be stored in the hidden fields of the Uniform Resource Locator (URL) that points to the file so that it can be used during successive invocations. This solution is expensive since the amount of state information in the context of applications accessing a database can be large. In such applications, the CGI-BIN file contains SQL commands that connect to the database, execute requests, disconnect from the database and pass the results to the browser. 
     A typical application is to browse a shopping catalog through the web, where the catalog itself is assumed to be stored in a database. As a customer browses through the catalog, the customer can select items to order. Among the selected items, the customer may further chose to place orders on some items and not to place orders on the rest. Thus the application and its interface to the database should allow the customer to selectively recover some of the selections (i.e., not place orders on some selections) the customer made prior to making the payment. To support recoverability at a later stage, information about all selections should be maintained. Hence state information should be maintained across invocations of the CGI-BIN file. 
     Application Ser. No. 08/491,742, filed Jun. 19, 1995, entitled &#34;ACCESSING A RELATIONAL DATABASE OVER THE INTERNET USING MACRO LANGUAGE FILES&#34;, is an example of an interface for web applications accessing a database. The CGI-BIN program in the interface parses SQL commands in macro language files, connects to the database, executes the commands and returns results to the web browser. Since the program is alive only for the duration of a request, state information cannot be stored in the program. 
     Since commercial database systems support a flat transaction structure and since the program cannot maintain state information across invocations, applications that have different transaction requirements cannot be supported. An interface that can support all of such applications is previously unknown. 
     SUMMARY OF THE INVENTION 
     It is an object of this invention to provide an interface to support applications that require selective recoverability and that require a transaction structure that is a combination of flat, nested and chained transaction models. 
     It is a further object of this invention to provide an interface for web applications interacting with data in a database wherein the web applications have different requirements in terms of the functional support provided to them. 
     The system, method, and program of this invention enables a browser to interact with data in a database. A web application is invoked to parse the requests from the browser and to send the parsed requests to an interface backend. The interface backend retains a connection with a database management system across multiple invocations of the web application. The interface backend processes the parsed requests and returns results from the database management system to the web application for display to a user. In processing the parsed requests, the interface backend has the capability to provide different functionality to the application, depending upon the requirements of the application for a given invocation of the application. When required, the interface backend can provide for selective recoverability and can support various transaction structures. 
     To provide such support, the interface backend can provide the following features: 1) The interface to the database is connection oriented; 2) The backend of the interface is long living; 3) State information about a session in progress is maintained; 4) State information is distributed between the backend and the hidden fields of the HTML output document; 5) The interface supports both recoverable and irrecoverable actions; and 6) The interface supports web applications with structures that cannot be handled by the flat transaction model of database systems. 
     However, not all of these features are required at all times. For example, some subtransactions within the application may indeed represent a flat transaction which may be handled in a similar way as conventional applications accessing a database. Other applications or subcomponents of an application may require certain features but not others. Some of these optional features include 1) whether a connection with a database is retained across a plurality of invocations of the web application, or whether the connection with the database is established and destroyed every time the web application is invoked; 2) whether there needs to be a transient backend which terminates after every invocation of the web application, or whether there needs to be a long living backend which exists across multiple invocations; and 3) whether or not state information about a session in progress is maintained. Depending upon which of the above functions are provided, and in what combination, the interface of this invention will provide different support for applications with different requirements, such as whether or not there is a need to support a plurality of sessions; whether or not a consistent database view needs to be maintained; and whether or not there is a need for further support for selective recoverability and further support for complex transaction structures. 
     The same backend of the interface of this invention can dynamically provide various combinations of these optional features, for each session or within a session, in order to meet the requirements of various applications. In addition, the backend of the interface can provide specific functionality in order to support web applications accessing a database requiring selective recoverability and supporting complex transaction structures through additional logic at the backend that is not needed for applications requiring less functionality. 
     To activate this additional logic in the backend, a web application must indicate, with a keyword prefix, whether an update request, i.e., interaction, is recoverable or irrecoverable, and must identify the scope of an explicit COMMIT request. An explicit ROLLBACK request can be issued to rollback those updates identified as recoverable. 
     The interface backend parses every update statement. For recoverable updates, the backend maintains an identifier and a compensating update. The identifier is passed back to the application to be used in a subsequent commit or rollback request. 
     Then, if the application issues an explicit COMMIT request, every recoverable update, in the scope of the COMMIT, having its identifier, is committed. Those recoverable updates not identified with their identifier in the COMMIT request are undone via a corresponding compensating update, if possible. Also, recoverable updates not identified with their identifier in a ROLLBACK request are committed. Otherwise, the identified recoverable updates within the scope of a ROLLBACK request are undone. 
     In addition, for requests that require an &#34;open cursor&#34; to be maintained, (scrolling over the rows of a large relation) the backend maintains a cache of the rows returned to the application. The backend also prefetches rows in anticipation of future requests, so that such requests can be satisfied from the cache. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     For a more complete understanding of this invention, reference is now made to the following detailed description of the embodiments as illustrated in the accompanying drawing, wherein: 
     FIG. 1 is an example of a travel agency database application. 
     FIG. 2 shows the architecture of the interface between web applications and databases. 
     FIG. 3 shows various combinations of the features of the interface of this invention that can be used for various different types of applications having different design criteria. 
     FIG. 4 shows the sequence of update requests in the travel agency application of FIG. 1 for describing an implementation of the interface of this invention. 
     FIG. 5A and 5B is a timing diagram including pseudo code for showing the functionality of a browser, a network, a webserver, a cgi-bin application, the backend interface, and a database management system (DBMS) in carrying out the method, system and program of this invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Some definitions for terms that are used throughout this document are as follows: 
     CGI-application: A CGI-application is an application that is invoked by the web browser in order to perform the actions that the user requested. This application is placed in the CGI-BIN directory and is executed (instead of displayed) when the user accesses the file through the web browser. In order to access a database, the application typically contains a SQL program. 
     Session: A session is defined as a sequence of requests that a user issues to the database. Each request in the sequence can require inputs from the user of the session or can depend on the results from previous requests to the database. A session can be thought of as a conversational transaction in the real world. 
     HTML document: A HTML document is a HTML file that contains requests to the database. On every invocation, the CGI-application is given one such file from which it reads the requests to be passed on to the database. The CGI-application places state information in the hidden fields, i.e., in fields transparent to a user of the browser, of the HTML document to be used during subsequent invocations. 
     Interaction: An interaction between a web application and a database typically consists of a sequence of actions. In database terminology these actions can be either retrievals or updates. Interacting with data in a database includes not only the capability of reading the data, but also possibly, but not necessarily, changing the data in the database. 
     Retrievals: Retrievals are actions that only &#34;read&#34; data from the database. 
     Updates: Updates are actions that modify data that is stored in the database. Updates can be one of two types: recoverable and irrecoverable. 
     Recoverable: Recoverable updates can be undone at any time during a session. 
     Irrecoverable: Irrecoverable updates cannot be undone during a session once they are performed. 
     The architecture of the interface of this invention is shown in FIG. 2. The frontend of the interface is the CGI-application 201 that parses requests from HTML documents 221, 222 made available to it by the web browser 210. The CGI-application 201 is alive only for the duration of a request. In order to maintain state information across invocations, the CGI-application 201 transmits parsed requests 231, 232 to the backend 240. The interaction between the frontend 201 of the interface and the database 250 takes place through the backend 240. The backend 240 interacts with the database 250 and maintains state information for a session. 
     The interaction between the frontend 201 of the interface and the database 250 can fall into one of the two categories: 1) connection oriented, or 2) connectionless. 
     Connection oriented: The connection with the database 250 is retained across several invocations of the CGI-application 201. 
     Connectionless: The connection with the database 250 is established and destroyed every time the CGI-application 201 is invoked. 
     The backend 240 itself can be categorized as belonging to one of the following types: transient backend or long living backend. 
     Transient backend: The backend 240 terminates after every invocation of the CGI-application 201. 
     Long living backend: The backend 240 exists across multiple invocations. 
     In order to support the flexibility of selectively recovering updates, some state information about a session should be maintained. State information can be classified into two categories: 1) private, or 2) public. 
     Private: This contains information about a session in the form of compensating actions for all recoverable actions and information about the database state as perceived by the user. 
     Public: This contains information about a session in progress (in the form of a session identifier) and a query being executed currently. 
     The following are examples of different kinds of state information that should be maintained during a session. 
     1) A user may be browsing through the result of a query during a session. In order to be able to look at small portions of the result each time, the database should maintain an open cursor for the query. Information about the open cursor should be maintained across several invocations of the CGI-application. 
     2) To support the notion of selective recoverability, compensating updates for all recoverable updates should be maintained. 
     Features of the Interface 
     The interface, of this invention, between web applications 201 and databases 250, has the following features in order to provide the requirements of selective recoverability and the support of different transaction models. 
     First, the interface to the database is connection oriented. During the duration of a session, a user may browse through a very large relation, looking only at a specified number of rows each time. The ideal solution with current database technology is to maintain an open cursor on the relation. If the database connection is to be established each time a specified number of rows is requested, a cursor should be opened at a specified position in the relation for each request. This is very inefficient. Also, if the cursor is to be opened at an isolation level that prevents updates on the relation during the time the cursor is open, it is important to keep the cursor open for a consistent view of the relation. This consistency cannot be guaranteed if the cursor has to be opened each time rows are requested. Hence, the interface to the database is connection oriented. 
     Second, the backend 240 of the interface must be long living. The CGI standard specifies that the CGI-application 201 be executed every time the user accesses the CGI-application 201. However, the result(s) of the CGI-application are not visible to the user until the program terminates. In order to make the interface to the database connection oriented, the CGI-application 201 must communicate with the backend 240 that retains the connection with the database. The CGI-application 201 could now send the user requests to the backend 240 that in turn interacts with the database 250 and retains the database connection for the duration of a session. To retain the connection with the database, the backend is long-living. 
     Third, state information about a session in progress must be maintained. During the duration of a single session a user would typically make more than one update. In order to let the user cancel a previous recoverable update, state information about all recoverable updates performed during a session is necessary. Information about open cursors, if any, is also required for efficiency and consistent database view. 
     Fourth, state information must be distributed between the backend and the HTML document. To illustrate, consider again the situation of a user browsing through a very large relation, looking at a specified number of rows each time. If both the private and public state information is maintained in the HTML document, each request for more rows must be translated into opening a new cursor and determining where the fetch operation must begin. This is clearly very expensive. Hence, the state information should not be maintained entirely in the HTML document. 
     Neither can the state information be maintained entirely at the backend because the CGI-application must have enough information about a session in progress (such as a session identifier) to interface with the appropriate backend. 
     Hence, the state information is distributed between the backend and the HTML document. The ideal distribution maintains only the relevant state information at each end. The backend maintains database related state information, including compensating actions for recoverable actions. The HTML document has information about a session in progress. Hence the private state is maintained by the backend, and the public state is maintained in the HTML document. 
     Fifth, the interface supports both recoverable and irrecoverable actions. To illustrate, consider the scenario where a user would like to purchase goods through the web browser. The user browses through the catalog and selects items to be purchased just as a person would select goods into a shopping cart. However these actions must be recoverable, i.e., the user must be allowed to cancel the selections at any time until the goods are purchased, just as a person is allowed to replace goods back on the shelves in a store. On the contrary, once the user has made the commitment to pay (i.e., give credit card number), all the actions of selecting items must be made irrecoverable in the same session i.e the user should not be allowed to cancel the order. (However, it should be noted that the customer may however initiate a new session for canceling orders.) Since commercial database systems do not provide support to selectively recover updates within a transaction, this support is provided outside of the database system by the interface of this invention. 
     Sixth, the interface supports web applications with structures that cannot be handled by the flat transaction model of database systems. The travel agency application discussed previously is an example of an application that cannot be supported by the flat transaction model offered by database systems. Hence support for such structures is provided outside of the database in the interface of this invention. 
     Various embodiments of this invention may include some, but not all of the above described features. These other embodiments may sacrifice some of the interface&#39;s flexibility. The necessity of some of the features described above depends upon the design decisions of each web application. To aid designers of web applications in designing an interface suitable for their applications, an identification of the features that could be supported by various design decisions is presented hereinbelow. 
     FIG. 3 shows various combinations of the features of the interface of this invention that can be used for various different types of web applications having different design criteria. 
     For example, Model 1, 301 can support applications that do not require support for sessions and recoverability. Sessions cannot be supported because the backend is not connection-oriented. Recoverability cannot be supported without state information. 
     Model 2, 302 is architecturally similar to model 1, 301 and can support exactly the same type of applications as model 1. However, an interface designed based on model 2 may have a minor performance improvement over interfaces based on model 1 since the backend is long living. 
     With model 3, 303 interfaces, all state information is maintained in the HTML document. This is because the backend is transient. Since status information is available, sessions are still possible. However, since the backend is not connection-oriented, consistent database views cannot be guaranteed. Additional logic to support non-flat transaction structures and recoverability can be added to the backend. 
     Model 4, 304 supports the same type of applications as model 3. The long living backend can contribute to some minor performance improvement in model 4 interfaces. 
     The notion of being connection-oriented and having a transient backend do not go together with relational database servers. The process requesting a database connection must remain alive during the duration of the connection. Hence interfaces based on model 5, 305 cannot support web applications accessing a database. 
     Model 6, 306 interfaces can support sessions, since the backend retains connection with the database during the duration of a session and is long living. No state information is maintained. Hence, selective recoverability cannot be supported. 
     Interfaces based on model 7, 307 are similar to those based on model 5, 305 and cannot support web applications accessing database servers. 
     Model 8, 308 guarantees sessions because the backend is long living and maintains connection with the database during the duration of a session. Consistent database views and recoverability can be supported since state information is preserved. Additional logic to support complex application structures can be added to the backend. 
     Each of the models above describes the functionality or the role that the backend plays during a session. The type of application an interface can support depends on the functionality the backend delivers. The backend can be requested to dynamically alter its role for each session or within the duration of a session. By doing so, the backend provides different functionally to different applications depending on the requirements. 
     A GENERAL INTERFACE FOR WEB APPLICATIONS USING A DYNAMIC BACKEND 
     The general interface of this invention, which supports applications having requirements of selective recoverability and non-flat transaction structures, has a backend that can dynamically alter the functionality it delivers depending on the requirements of the session. 
     At any point during a session, the CGI-application 201 can request the backend 240 to provide the functionality of a particular model described above. 
     To provide the functionality of selective recoverability and support for transaction structures that are different from the flat transaction structure, backends have additional logic incorporated in them. This is because database systems do not support either of these requirements. However, the following support is required from web applications for the additional logic in the backends to be active. 
     Program Logic Support in Web Applications: 
     1. All update requests from the application must be prefixed with a RECOVERABLE or IRRECOVERABLE keyword. 
     2. An explicit COMMIT request must identify the scope of the COMMIT, (in the form of identifiers of updates at the beginning and end of the scope) and the RECOVERABLE updates to be committed. 
     3. An explicit ROLLBACK request can be issued to rollback a recoverable update. 
     When the above logic is activated, the backend initiates two transaction threads-one handle all recoverable updates, &#34;R-thread&#34; and another to handle irrecoverable updates, &#34;IR-thread&#34;. The backend parses every update statement to identify the thread that should handle the statement. The R-thread generates and maintains an identifier and a compensating update for every recoverable update. The identifier is passed back to the applications to be used subsequently in an explicit COMMIT or ROLLBACK request. 
     The scope of a COMMIT/ROLLBACK consists of all the statements occurring after a preceding COMMIT/ROLLBACK up to the current statement. A recoverable update that is in the scope of a COMMIT, but not identified in the request is undone by executing a corresponding compensating update, if possible. Similarly, a recoverable update in the scope of a ROLLBACK but not identified in the request is assumed to be committed. 
     Thus, the explicit COMMIT and ROLLBACK requests provide for selective recoverability by allowing selection of updates that should be committed (rolled back). The scope associated with the COMMIT/ROLLBACK enables both nested and chain transaction models to be supported. 
     For a further understanding, FIG. 4 shows the sequence of update requests in the travel agency application of FIG. 1. For the sake of clarity, queries have not been shown in the example. Identifiers 401 (like Lawn Care, RAB, RA, etc.) are update identifiers generated by the backend to be used in an explicit COMMIT request. Updates (RBC, RCD) do not appear in the explicit COMMIT request, and the R-thread compensates for these (RBC, RCD) by issuing compensating updates to the database. 
     The additional logic for supporting recoverability and non-flat transaction structures is disabled for the duration of the Home-Care agency subtransaction which has a flat structure. The logic is enabled for the other subtransactions which require support for selective recoverability. 
     It must be noted that the above rules hold only for applications requiring the flexibility of selective recoverability and complex transaction structures. The backend disables the additional logic whenever it is requested to supply the functionality of the model that does not support these requirements. 
     ARCHITECTURE OF THE GENERAL INTERFACE 
     As previously discussed, the architecture of the general interface is shown in FIG. 2. A self-describing file, e.g., a HTML document, 221 contains requests to the database 250. The CGI-application 201 parses the document 221 and transmits the requests 231 to an appropriate backend 240. Backends can be requested to provide the functions of any of the eight models discussed earlier. Information about all existing backends and their functionality is available in a file 260 that is shared between CGI-applications. A backend that is part of an ongoing session is said to be &#34;bound&#34; to the session and delivers the functionality the session expects. Otherwise, the backend is &#34;idle&#34;. 
     If the user requests are part of an ongoing session, the CGI-application transmits the requests to the backend that is bound to the session. In the absence of a backend that is bound to a session, either an existing idle backend is requested to provide the required functionality for the new session or a new one is created and bound to the session. 
     The backend transmits generated identifiers for recoverable updates to the CGI-application. The CGI-application generates session identifiers for new sessions and places update identifiers and session identifiers in the hidden fields, i.e., fields transparent to a user of the browser, of the self-describing file to identify future requests. 
     For requests that require an &#34;open cursor&#34; to be maintained, (scrolling over the rows of a large relation) the backend maintains a cache of the rows returned to the application. The backend also prefetches rows in anticipation of future requests, so that such requests can be satisfied from the cache. 
     Connection-oriented backends timeout and disconnect if they are idle for a long time. A CGI-application can cause the backend bound to a session associated with the application to terminate or disconnect with an explicit TERMINATE or DISCONNECT request. 
     SYSTEM, METHOD, AND PROGRAM OF OPERATION 
     FIG. 5A and 5B is a timing diagram including pseudo code for showing the functionality of a browser 210, a network 520, a webserver 530, a CGI-application 201, the backend interface 240, and a database management system (DBMS) 250 in carrying out the method, system and program of this invention as discussed above. 
     With reference to FIG. 5A, the browser 210, will send to the webserver 530, via the network 520, the following URL &#34;url=&lt;websrvname, cgi-bin, delimited parameter list&gt;&#34; 501 along with any required parameters 512, step 514. The URL 501 specifies the name of the webserver and the CGI-application. In addition, the URL, through the delimited parameter list 511, can specify object identifiers (ids) for specifying, among other things, SQL statements, form layouts, etc. The required parameters that the browser must send include the transaction identifier (txnid) if one exists, or a null field, i.e., an uninitialized transaction id (txnid) if it is the beginning of a transaction. The transaction id is the means that is used for tying the requests and results together since the browser is transient and does not maintain any state information. In this way, transactional functionality is provided on a connectionless protocol, i.e., the world wide web. As such, atomic work is maintained across multiple connections. 
     The required parameters 512 may also include compensating SQL statements for recoverable transactions in support of non-flat transaction structures. The required parameters may also specify which language the CGI-application or the self-describing file is written in, thereby supporting multiple browser standards. As such, this invention supports applications or appletts written to various formats. The required parameters are embedded in the hidden fields of an HTML document or other self-describing file. As such, various browser standards can be supported based upon the data maintained and exchanged between the browser and the backend interface. 
     The required parameters may also include cursor position information, e.g., current begin and current end, if there is an open cursor and scrolling is desired. If a row or rows of results have been returned to the browser, and scrolling is desired, the browser will send &#34;EGET NEXT `N` ROWS&#34; 513 to the webserver. This may be a button that is selected by a user on a browser form. The browser will then send the URL 501 and the required parameters 512. 
     The network 520 routes all messages, e.g., the &#34;GET NEXT `N` ROWS&#34;, and the URL and the required parameters, to the webserver specified in the URL 501, step 522. The webserver is the front-end of the interface 201 as shown in FIG. 2. 
     Referring back to FIG. 5A, the webserver 530 instantiates the CGI-program identified in the URL 501 within the delimited parameter list, e.g., in a header, along with the remaining delimited parameters, step 532. The CGI-application can comply with any one of many standards including, but not limited to, Java, C/C++, Fortran, PERL, TCL, any UNIX shell, visual basic, AppleScript, appletts, ODBMS, and/or the various HTML standards. 
     The CGI-application parses, step 562, the parameter lists, the delimited parameter list 511 specified in the URL including SQL statements and the required parameters 512, using a macro language file applicable to whatever language and/or passing through the CGI-application to a facility, e.g., Java, that interprets the parameters. The use of a macro language file can be one as described in application Ser. No. 08/491,742, filed Jun. 19, 1995, entitled &#34;ACCESSING A RELATIONAL DATABASE OVER THE INTERNET USING MACRO LANGUAGE FILES&#34;, herein incorporated by reference. The type of parsing done by a macro language file depends upon the language that the CGI-application was written in. The required parameters 512 in the hidden fields of the self describing file, e.g., a HTML document, can also specify the language of the CGI-application and the a type of parsing to be performed, such as by a specific macro language file. 
     Also, the CGI-application extracts the transaction id, if there is one, and sets the current begin position and the current end position of the open cursor, steps 563, 564. If a backend does not exist, a backend process is spawned, step 566. Then the parsed parameters, transaction id, and begin/end cursor position are passed to the spawned or pre-existing backend, step 567. 
     It should be noted that for one backend parent process that has been spawned and is currently existing, there will be one thread spawned for all of the irrecoverable transactions and a separate thread will be spawned for each recoverable transaction. That is, each recoverable transaction will have its own process, i.e., thread. 
     The backend 240 then performs the following steps. If the transaction id is not set, the backend 240 generates a unique transaction id (txnid), and sets it as the &#34;txnid,&#34; step 541. If the transaction is declared &#34;irrecoverable,&#34; the transaction is passed to the irrecoverable thread, step 542. If the transaction is declared &#34;recoverable&#34;, the backend looks into a table of &lt;txnid, thread id&gt; to determine whether a thread has been spawned for that transaction. If so, the SQL, i.e., the parsed delimited parameter list 511 and the parsed required parameters 512 are passed to the thread. If no thread has been spawned, a thread is forked, and the &lt;txnid, thread id&gt; is recorded in the lookup table, step 543. The parameters 511, 512 are passed to the spawned or pre-existing thread having the corresponding thread id, step 544. 
     With reference to FIG. 5B, the database management system, DBMS, 250 then returns results to the thread in the backend making the SQL call, step 551. 
     The backend 240 then returns the results to the CGI-application, step 546. The backend may optionally prefetch from the DBMS and cache a range of rows or additional results that is greater than what was originally requested from the browser (and what will be returned at step 546), step 547. This option is used to improve system performance and reduce time involved in accessing the DBMS whenever a &#34;GET NEXT `N` ROWS&#34; request is anticipated from the browser. Also, the backend may optionally timeout over a predetermined interval if the backend is inactive for that time interval. If the backend times-out, then it could disconnect from the DBMS 250. Otherwise, it can stay connected for the next invocation of the CGI-application, step 548. There are many other equivalent ways to implement this ability of the backend to stay connected to the DBMS through multiple invocations of the CGI-application. Likewise, by applying general techniques known in the art, one can implement this new ability for the CGI-application to control, based upon the requirements of the CGI-application, whether the backend should be long-living and stay connected to the DBMS over multiple invocations of the CGI-application, or be transient, and be disconnected after an invocation. Also, other means within a webserver may be used to provide CGI-application functionality as discussed herein. 
     Upon receipt of the results from the backend 240, the CGI-application formats the results into a HTML page or any other self-describing file or format. This can be accomplished through a macro language file such as described in application Ser. No. 08/491,742, filed Jun. 19, 1995, entitled &#34;ACCESSING A RELATIONAL DATABASE OVER THE INTERNET USING MACRO LANGUAGE FILES&#34;, herein incorporated by reference. The use of any such macro language file will determine the form the results will be put into. The CGI-application also sets the transaction id (txnid), current begin/end cursor position in the required parameter list 512, step 568. All of these items are sent to the webserver 530 and the cgi-bin process terminates step 569, i.e., the connection between the webserver and the CGI-application and between the CGI-application and the backend is lost. Any additional requests associated with that same transaction will be tied to this transaction through the transaction id (txnid) as if the connection were maintained. 
     The webserver 530 sends the format, e.g., the HTML pages, to the invoking browser, step 535. Since the browser may have been disconnected from this webserver since step 514, the webserver resolves the identity of the browser via a hidden field of the self-describing file, e.g., a HTML document, which contains the transaction id (txnid). The transaction id (txnid) is essentially the description of the virtual connection between the browser and the DBMS. 
     The network 520 routes the information from the webserver 530 to the browser 210, step 524. The browser 210 then displays the results to a user, step 515. 
     Using the foregoing specification, the invention may be implemented using standard programming and/or engineering techniques using computer programming software, firmware, hardware or any combination or subcombination thereof. Any such resulting program(s), having computer readable program code means, may be embodied within one or more computer usable media such as fixed (hard) drives, disk, diskettes, optical disks, magnetic tape, semiconductor memories such as ROM, Proms, etc., or any memory or transmitting device, thereby making a computer program product, i.e., an article of manufacture, according to the invention. The article of manufacture containing the computer programming code may be made and/or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network. 
     An apparatus for making, using, or selling the invention may be one or more processing systems including, but not limited to, cpu, memory, storage devices, communication links, communication devices, servers, I/O devices, or any subcomponents or individual parts of one or more processing systems, including software, firmware, hardware or any combination or subcombination thereof, which embody the invention as set forth in the claims. 
     User input may be received from the keyboard, mouse, pen, voice, touch screen, or any other means by which a human can input data to a computer, including through other programs such as application programs. 
     One skilled in the art of computer science will easily be able to combine the software created as described with appropriate general purpose or special purpose computer hardware to create a computer system and/or computer subcomponents embodying the invention and to create a computer system and/or computer subcomponents for carrying out the method of the invention. 
     While the preferred embodiment of the present invention has been illustrated in detail, it should be apparent that modifications and adaptations to that embodiment may occur to one skilled in the art without departing from the spirit or scope of the present invention as set forth in the following claims. For example, although reference is made to relational databases, other database, including but not limited to object oriented databases may be applicable to this invention. Also, although in a preferred embodiment the browser resides on a first processing system and the webserver, CGI-application, backend, and DBMS reside on a second processing system connected to the first system via a network, these various components could reside within various different combinations of processing systems and network environments.