Data processing: financial – business practice – management – or co – Automated electrical financial or business practice or... – Electronic shopping
Reexamination Certificate
1997-10-31
2001-12-25
Trammell, James P. (Department: 2162)
Data processing: financial, business practice, management, or co
Automated electrical financial or business practice or...
Electronic shopping
C705S027200, C707S793000, C707S793000
Reexamination Certificate
active
06334114
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to processing transactions in networked computer systems, and more specifically to processing multiple-request transactions in a stateless web environment.
BACKGROUND OF THE INVENTION
The World Wide Web includes a network of servers on the Internet, each of which is associated with one or more HTML (Hypertext Markup Language) pages. The HTML pages associated with a server provide information and hypertext links to other documents on that and (usually) other servers. Servers communicate with clients by using the Hypertext Transfer Protocol (HTTP). The servers listen for requests from clients for their HTML pages, and are therefore often referred to as “listeners”.
Users of the World Wide Web use a client program, referred to as a browser, to request, decode and display information from listeners. When the user of a browser selects a link on an HTML page, the browser that is displaying the page sends a request over the Internet to the listener associated with the Universal Resource Locator (URL) specified in the link. In response to the request, the listener transmits the requested information to the browser that issued the request. The browser receives the information, presents the received information to the user, and awaits the next user request.
Traditionally, the information stored on listeners is in the form of static HTML pages. Static HTML pages are created and stored at the listener prior to a request from a web browser. In response to a request, a static HTML page is merely read from storage and transmitted to the requesting browser. Currently, there is a trend to develop listeners that respond to browser requests by performing dynamic operations. For example, a listener may respond to a request by issuing a query to a database, dynamically constructing a web page containing the results of the query, and transmitting the dynamically constructed HTML page to the requesting browser. To perform dynamic operations, the functionality of the listener must be enhanced or augmented. Various approaches have been developed for extending listeners to support dynamic operations.
One of the major characteristics of the web is that it provides a stateless environment. That is, HTTP communicates information on a message-by-message basis without any mechanism for designating relationships between messages. This means that a process servicing a current request cannot determine whether the current request came from the same client as a previous request. In addition, the servicing process cannot determine how or if the current request relates to a previous request.
A disadvantage with using a stateless environment is that it is difficult to process multiple-request transactions. A multiple-request transaction is a set of operations that (1) are specified in more than one request, and (2) must be performed as an atomic unit of work. For example, a multiple-request transaction could consist of three separate operations, such as buying stock item A, selling stock item B and updating the inventory to reflect the number of stock items on hand. Each of these three operations may be specified in a separate request, but each operation should only be performed if all three operations can be performed. In order to properly determine that buying stock item A, selling stock item B and updating the inventory are from the same single transaction requires that transaction state information be retained by the servicing process that receives the three requests.
One possible solution to the stateless problem is to spawn a servicing process for each request-issuing source (each “client”). Each time a request from a client is received, the same servicing process is called upon to process the request. Because the same process is invoked for a given client, the transaction state information for a particular transaction can be maintained by the associated servicing process, thus allowing for the processing of multiple-request transactions.
This solution has significant drawbacks, however. First, maintaining a separate servicing process for each client is wasteful since most clients do not continually make requests to the servicing process. Between client requests, the servicing process simply waits, consuming system resources, without performing any work. A second drawback with this solution is that it is non-scalable. If a servicing process is spawned and maintained for each client, system resources would quickly be consumed, even for a relatively small number of clients. Therefore, spawning a servicing process for each client is not a viable solution for large scale systems.
A second possible solution is to require each servicing process to maintain the current state of the transactions that it is currently processing. By maintaining transaction state information, each servicing process can ensure that multiple-request transactions are processed correctly. However, a drawback associated with requiring each servicing process to maintain transaction state information is that it puts a burden on the developer of each servicing process to write extra code in order to maintain the required transaction state information.
Based on the foregoing, it is desirable to provide a mechanism for processing multiple-request transactions in a stateless environment that does not require a servicing process to maintain transaction state information.
SUMMARY OF THE INVENTION
A method and system for processing multiple-request transactions in a stateless environment is provided.
According to one aspect of the invention, a cartridge execution engine intercepts browser messages directed to a cartridge. The cartridge execution engine determines whether the browser messages are associated with transactions. If the browser messages are associated with transactions, then the cartridge execution engine sends transaction control messages to a transaction manager. The cartridge execution engine also sends operation messages to the cartridge. The cartridge performs the operations specified in the operation messages. In response to the transaction control messages from the cartridge execution engine, the transaction manager causes the multiple-request transactions to be either committed or rolled back as an atomic unit of work.
According to another aspect of the invention, the browser messages associated with transactions are associated with transaction IDs that can be used to identify a browser that is associated with a particular browser message.
According to another aspect of the invention, the browser messages associated with transactions are associated with transaction IDs and are used to identify a browser associated with a particular browser message.
According to another aspect of the invention, the transaction IDs are maintained as cookies on the browser that is associated with the particular browser message.
According to another aspect of the invention, the transaction IDs are maintained as URLs on the browser that is associated with the particular browser message.
REFERENCES:
patent: 4918595 (1990-04-01), Kahn et al.
patent: 5210824 (1993-05-01), Putz et al.
patent: 5212793 (1993-05-01), Donica et al.
patent: 5249290 (1993-09-01), Heizer
patent: 5329619 (1994-07-01), Page et al.
patent: 5341478 (1994-08-01), Travis, Jr. et al.
patent: 5361350 (1994-11-01), Conner et al.
patent: 5457797 (1995-10-01), Butterworth et al.
patent: 5504897 (1996-04-01), Gans et al.
patent: 5546584 (1996-08-01), Lundin et al.
patent: 5592654 (1997-01-01), Djakovic
patent: 5613148 (1997-03-01), Bezviner et al.
patent: 5623656 (1997-04-01), Lyons
patent: 5706442 (1998-01-01), Anderson et al.
patent: 5708780 (1998-01-01), Levergood et al.
patent: 5715314 (1998-02-01), Payne et al.
patent: 5724424 (1998-03-01), Gifford
patent: 5737592 (1998-04-01), Nguyen et al.
patent: 5737607 (1998-04-01), Hamilton et al.
patent: 5745681 (1998-04-01), Levine et al.
patent: 5752246 (1998-05-01), Rogers et al.
patent: 5761507 (1998-06-01), Govett
patent: 5761662 (1998-06-01), Dasan
patent: 5761673 (1998-06-01), Bookman et al.
Adunuthula Seshu
Anand Mala
Jacobs Lawrence
Brandt Carl L.
Hickman Palermo & Truong & Becker LLP
Oracle Corporation
Retta Yehdega
Trammell James P.
LandOfFree
Method and apparatus for performing transactions in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for performing transactions in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for performing transactions in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2569029