Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-10-22
2004-09-28
Homere, Jean R. (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C709S203000, C709S219000, C718S101000
Reexamination Certificate
active
06799188
ABSTRACT:
COPYRIGHT NOTICE
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
The present invention relates generally to information processing environments and, more particularly, to computer-implemented methodology related to two-phase commit decisions in transaction processing systems.
2. Description of the Background Art
Today, most computers are linked to other computer systems via a computer network. Well-known examples of computer networks include local-area networks (LANs) where the computers are geographically close together (e.g., in the same building), and wide-area networks (WANs) where the computers are farther apart and are connected by telephone lines or radio waves.
Often, networks are configured as “client/server” networks, such that each computer on the network is either a “client” or a “server.” Servers are powerful computers or processes dedicated to managing shared resources, such as storage (i.e., disk drives), printers, modems, or the like. Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. For instance, a database server is a computer system that manages database information, including processing database queries from various clients. The client part of this client-server architecture typically comprises PCs or workstations which rely on a server to perform some operations. Typically, a client runs a “client application” that relies on a server to perform some operations, such as returning particular database information. Often, client-server architecture is thought of as a “two-tier architecture,” one in which the user interface runs on the client or “front end” and the database is stored on the server or “back end.” The actual business rules or application logic driving operation of the application can run on either the client or the server (or even be partitioned between the two). In a typical deployment of such a system, a client application, such as one created by an information service (IS) shop, resides on all of the client or end-user machines. Such client applications interact with a host database system (e.g., Borland Interbase®), which execute business logic (e.g. within database stored procedures) that traditionally ran at the client machines.
Database systems are well documented in the technical, trade and patent literature. See e.g., Date, C. “An Introduction to Database Systems, Volume I and II,” Addison Wesley, 1990, the disclosure of which is hereby incorporated by reference. A more technical review is provided by Gray, J. and Reuter, A., “Transaction Processing: Concepts and Techniques,” Morgan Kaufmann Publishers, 1993, the disclosure of which is hereby incorporated by reference.
More recently, the development model has shifted from standard client/server or two-tier development to a three-tier, component-based development model. This newer client/server architecture introduces three well-defined and separate processes, each typically running on a different platform. A “first tier” provides the user interface, which runs on the user's computer (i.e., the client). Next, a “second tier” provides the functional modules that actually process data. This middle tier typically runs on a server, often called an “application server.” A “third tier” furnishes a database management system (DBMS) that stores the data required by the middle tier. This tier may run on a second server called the database server.
Three-tier database systems are well documented in the patent and trade literature; see, e.g., U.S. Pat. No. 6,266,666, entitled “Component transaction server for developing and deploying transaction-intensive business applications”, the disclosure of which is hereby incorporated by reference.
The three-tier design has many advantages over traditional two-tier or single-tier designs. For example, the added modularity makes it easier to modify or replace one tier without affecting the other tiers. Separating the application functions from the database functions makes it easier to implement load balancing. Thus, by partitioning applications cleanly into presentation, application logic, and data sections, the result will be enhanced scalability, reusability, security, and manageability.
In the three-tier model, communication must occur among the various tiers, such as from a client to a middle tier, and from the middle tier to one or more back-end databases. One of the advantages of employing a middle tier is to pool together connections to the database in a central (middleware) tier, thus allowing more efficient access to the database. In particular, database connections, which are expensive in terms of system and network resources, are cached in the middle tier.
Another advantage of the middle tier is to offload certain computations from the back-end databases, particularly those pertaining to business logic (i.e., business objects). Exploiting this advantage, a system administrator would deploy a middle tier on a separate server computer, one that was physically separate from the computers hosting the back-end databases.
In many cases, a particular application may access and modify data that is stored in several different databases, including ones provided by different vendors. For example, a banking application may access customer checking account information stored in one database as well as savings account information stored in a second database. In commercial transaction processing systems there is frequently a need to coordinate the process of making changes to multiple databases because a single transaction can update many different databases. For example, in a consumer banking application, an account holder may wish to transfer $500 from his or her savings account to his or her checking account. This transaction actually involves a pair of operations. The first operation is to remove (or debit) $500 from the savings account. The second operation is to add (or credit) $500 to the checking account. Both the bank and the account holder want to ensure that if the bank's computer system crashed in the middle of this transfer, there is a way to make sure that either the $500 is posted to the checking account, or, alternatively, that the $500 is not removed from the savings account. It is unacceptable if the funds are removed from savings, but are not credited to checking. In other words, this transaction requires a mechanism to guarantee “atomicity.” Atomicity means that all actions that take place as part of a transaction are executed as a single atomic operation and that either they all complete, or none of them complete.
In transactions involving a single database, atomicity typically involves the following operations which are all handled as part of the standard operations of the database management system:
1. Begin: Beginning a transaction creates a transaction scope. From the time the transaction is begun until it is successfully committed or rolled back, operations against the database will be within the scope of the transaction and will either all succeed or all fail.
2. Commit: Committing a transaction tells the database that all processing has completed satisfactorily, and that the results should be written to persistent storage. Before a commit is issued, changes may be undone by issuing a “rollback” command. If there is a system crash prior to a commit, on recovery the database will revert to the state it was in before the transaction was begun. Executing the commit ends the transaction.
3. Rollback: Rolling back a transaction revokes any changes that occurred during the transaction, leaving the database in the state in which it was found prior to the transaction. After a transaction is committed, it can no longer be ro
Borland Software Corporation
Homere Jean R.
Riddle G. Mack
Smart John A.
Wong Leslie
LandOfFree
Transaction processing system providing improved methodology... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transaction processing system providing improved methodology..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transaction processing system providing improved methodology... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3261544