Patent Grant
7653628
The field of invention is related generally to enterprise software; and, more specifically, to persistent data management with different isolation levels.
The information systems of a modern day enterprise (such as a corporation or government institution) are often responsible for managing and performing automated tasks upon large amounts of data. Persistent data is that data that “exists” for extended periods of time (i.e., “it persists”). Persistent data is typically stored in a database so that it can be accessed as needed over the course of its existence. Here, complex “database software” (e.g., such as DB2, Oracle, and SQL Server) is often used to actually read the data and perhaps perform various intelligent functions with it. Frequently, persistent data can change over the course of its existence (e.g., by executing a series of reads and writes to the data over the course of its existence). Moreover, multiple items of different persistent data may change as part of a single large scale “distributed transaction”.
A distributed transaction is a transaction that involves more than one database or server. Distributed transactions frequently involve multiple databases accessed through multiple servers that are interconnected by a network. Because of the use of multiple databases, distributed transactions are an attempt at some sort of comprehensive function that serves the enterprise's needs. For example, in the case of an airline, a single distributed transaction might be used to manage an internet connection to a potential customer who may reserve a particular seat on a particular flight. Here, note that a number of different databases may be involved in a single distributed transaction that is executed for the customer's experience with the airline's on-line ticketing and reservation system.
For example, assume the distributed transaction is expected to: 1) provide the potential customer with flight scheduling, pricing and seating information; 2) record the customer's name, address, credit card, and email information if any flight is reserved by the customer; 3) update the seating information for each seat reserved by the customer; 4) update the customer's frequent flier mileage records if the customer is registered in the airline's frequent flier program; 5) update the airline's accounting records to reflect the new revenue introduced by each flight reservation made by the customer; and, 6) invoice the customer using the customer's credit card information.
Here, a number of different databases may be involved in the distributed transaction such as: 1) a first database that keeps track of the airline's flight scheduling information; 2) a second database that keeps track of information specific to a particular flight such as seating information; 3) a third database that keeps track of flight pricing information; 4) a fourth flight that keeps track of each customer's name, address and email information; 5) a fifth database that keeps track of each frequent flier's mileage; 6) a sixth database that keeps track of the airline's accounting records; and 7) a seventh database that keeps track of the airline's invoicing records.
a and 1b depict how a distributed transaction is typically carried out by an enterprise's information system infrastructure. A protocol, referred to as the “two-phase commit” protocol is used to ensure that either a distributed transaction's database updates are successfully completed in their entirety; or, the distributed transaction is not effected at all. By ensuring that database updates for a distributed transaction are either completely carried out or not carried out at all, incorrect database records are avoided (e.g., a seat being reserved for a reservation that is not actually made, a seat not being reserved for a reservation that is actually made, etc.).
The example of
Each server 1011 through 1014 includes its own resource manager module 1031 through 1034 that is responsible for communicating with a particular database. The resource manager can often be viewed as driver software that is used to send specific functional commands to the database software in response to requests/commands made by higher level software functions. The commands sent to a database are typically scripted in some form of database language (e.g., Structured Query Language (SQL)). Examples of resource managers include a Java Database Connectivity (JDBC) driver that is presently part of the J2EE platform and an Open Database Connectivity (ODBC) driver provided by Microsoft Corporation.
A transaction manager module 104 is responsible for, typically among other responsibilities, implementing the two-phase commit protocol with those resource managers that communicate to a database that is to be updated after a distributed transaction's calculations have been executed. In the examples of
Once a distributed transaction's calculations are completed so that all database changes to be made as a consequence of the transaction's execution are known (e.g., entry of a specific reserved seat on a specific flight, etc.), the first phase of the two-phase commit protocol begins with the transaction manager 104 receiving a “commit” command 1 from another portion of the distributed transaction's software (e.g., “a client” or “container” that executes higher level functions of the distributed transaction). In response to the received “commit” command 1, the transaction manager 104 sends “prepare” commands 2 to each of the resource managers 1031 through 1034. Note that, because a network 105 resides between the server 1011 that contains the transaction manager 104 and servers 1012 through 1014, those of the “prepare” commands 2 that are sent to servers 1012 through 1014 pass through network 105.
In response to the received “prepare” commands 2, each resource manager forwards a “prepare” command 3 to its corresponding database in the appropriate language format (e.g., SQL). Each database 1021 through 1024 performs what is akin to a “soft write” of the new, updated information. That is, for example, each database runs through all internal routines just short of actually writing the new, updated information. If a problem is not detected by a database (e.g., an incompatibility in the data) just short of the actual write of the updated information, a database reports a “ready” response. In
A “rollback” response means that a database has recognized some problem in preparing itself to actually write its updated information. As a consequence, a “rollback” response essentially means that the new information cannot be written. Given that all new information of distributed transaction must be written or no new information from a distributed transaction may be written, as shall become evident in more detail immediately below, the “ready” response of each server in
In
The transaction manager's sending of a second set of messages in response to the received responses marks the beginning of the second phase. Because the transaction manager 104 receives all “ready” responses from the resource managers 1031 through 1034 in the situation of
In
a and 1b show an implementation where a single server is associated with each database. In more complicated implementations, multiple servers may be associated with each database.
In an environment where multiples servers are capable of updating a same database entry, contention may arise between servers. That is, two or more servers may desire access to the same data base entry at approximately the same time for purposes of updating the same database entry with new information at approximately the same time. Generally, basic principles of database operation (collectively referred to as “ACID” principles) stipulate that database data should be not be updated with new information without the update being visible to the various applications that might use the data. Because quasi simultaneous attempts at accessing and updating a same database entry by different servers may violate these principles, contention resolution should be built into “multi-server, single database” environments.
An enqueue server 203 facilitates contention resolution for database entries. An enqueue server keeps track of the database entries of database 202 that are currently being used by an application. If an application desires to use a particular database entry, the application's server sends a message to the enqueue server 203 that effectively requests permission to obtain access to the database entry.
According to a basic embodiment of operation, if the database entry is being used by another application, the enqueue server 203 denies access to the requesting application (e.g., by sending an “exception” message to the requesting application's corresponding server); or, if the database entry is not being used by another application, the enqueue server 203 approves access to the requesting application (e.g., by sending a “approve” message to the requesting application's corresponding server). In the later case, the requesting application's corresponding server fetches the data from the database 202.
A method is described for managing an application's cached persistent data with different isolation levels. The different isolation levels include: 1) requesting a lock for a first item of database data in response to the first item of database data not being cached and not yet having been used by the application; 2) requesting a lock for a second item of cached database data in response to the second item of database data being updated for a first time by the application; and, 3) requesting a lock for a third item of cached database data in response to it being confirmed that the third item of database data will need to be updated in its database.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
a (prior art) shows a two phase commit protocol distributed transaction that concludes with all updates being made to their respective databases;
b (prior art) shows a two phase commit protocol distributed transaction that concludes with no updates being made to any databases;
There may exist a tradeoff between performance and the degree to which a database entry that has been granted to a particular application is isolated from another application. For example, access to database entries based upon a strictly serialized (FIFO) scheme may result in reduced performance in some circumstances. Consider a situation where a conflict exists between a first application that requests access to a database entry even though the database entry may not actually be used and modified by the first application (e.g., the first application reads from the database, at the start of its execution, all of the database data that it “might” actually use) and a second application that will actually use the same database entry upon its request for it (e.g., an application that requests a read for a database entry just before it actually uses it).
Referring to
In order to improve performance, therefore, it may be useful at least in some operational circumstances to allow another application to be granted access to a database entry even though another application already has access to it. According to the example provided immediately above, granting the second application access to the database entry at issue would have been beneficial from a performance perspective because both distributed transactions would have been able to successfully complete their execution (i.e., the second application's distributed transaction would not be rolled back).
A database entry is data that can be particularly requested from a database (e.g., one or more table rows, one or more table columns, a scalar table value, etc.). A database entry isolation level is a rule that dictates when a competing application is not allowed access to a database entry. That is, a database entry isolation level corresponds to when a database entry is “locked” such that applications requesting the database entry will be given an “exception” response by the enqueue server.
Defining isolation levels that are tailored for particular operational circumstances should allow for granularized consideration of performance vs. isolation level throughout an application's execution. A component of granularized performance vs. isolation level consideration would be to allow a specific isolation level to be selected (from amongst a collection of isolation level choices) for each of a particular application's database entries and/or group of database entries. That is, because different operational circumstances can be gleaned at least from the manner in which an application uses the database entries or groups thereof that it reads from a database, granularized consideration of isolation level vs. performance may be realized by defining isolation level on a database entry by database entry basis (and/or group of database entries by group of database entries basis).
For example, a “less strict” isolation level may be defined for a first database entry that “might be” used by an application only after a long period of time has elapsed after it has been read from the database. Likewise, for the same application, a “more strict” isolation level may be defined for a second database entry that “will be” used immediately after it is read from the database.
The strictness of the disclosed isolation levels decreases from
Server 301, 401, 501 may be a Java 2 Enterprise Edition (“J2EE”) server node which supports Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer). Of course, other embodiments may be implemented in the context of various different software platforms including, by way of example, Microsoft .NET, Windows/NT, Microsoft Transaction Server (MTS), the Advanced Business Application Programming (“ABAP”) platforms developed by SAP AG and comparable platforms.
A persistent data management service can be viewed, at least in one instance, as a “faster” database because it utilizes storage elements (e.g., semiconductor memory) that are integrated closer to the processors that execute the application software than the actual database 302, 402, 502 itself. These proximate storage elements are generally referred to as a cache 306, 406, 506. Here, the application uses the persistent data management service largely as it would an external database (e.g., requesting database entries and updating database entries).
The persistent database management service manages cached database entries and communicates with the enqueue server 303, 403, 503 and external database 302, 402, 502 to read/write database entries from database 302, 402, 502 from/to cache 306, 406, 506. Because the function of the persistent data management service 305, 405, 505 is heavily involved with cached information, for illustrative convenience, cache 306, 406, 506 is drawn as being part of the persistent data management service 305, 405, 505 itself. Cache 306, 406, 506 can also be viewed as being the same cache.
According to the particular embodiment of
It is important to emphasize that the cached data entries and various software components of
The isolation level of
The persistent data management service 305 causes the request 3 that is sent to the enqueue server 303 to indicate that the desired database entry is to be immediately locked (so that other applications are denied access to it) if the enqueue server favorably responds to the request. Accordingly, a favorable response 4 to the request 3 is sent by the enqueue server 303 and the enqueue server locks the database entry (e.g., by listing it with those database entries deemed accessed by an application and therefore not available for the use of other applications). In response to its receipt of the favorable response 5, the persistent data management service 305 causes a read command 7 (e.g., in an SQL format) to be sent to the database 302 (by communicating 6 to the resource manager 308).
The database 302 provides 8 the desired database entry 309a, which is subsequently loaded 9 into cache 306. The persistent database management service 305 is then able to respond to the application's initial request 1 by providing 10 the desired database entry 309a. At some later time the application may process the data 310 and cause it to be restored in cache 12 as database entry 309b (note that database entry 309b may be “updated” by the application's processing 310 so as to contain one or more different values than it did prior to the application's processing 310).
The application 304 then continues its execution until completion. The application 304 may or may not involve or update the cached database entry in any of its executions subsequent to processing 310 and prior to the application's completion. Cached database entry 309c corresponds to the database entry at issue at the time the application's execution is complete. Some time after the application's execution is complete, if the cached database entry 309c corresponds to updated information that differs from the information contained in its originally loaded state 309a, the updated database entry 309c will need to written back to database 302 as part of the two-phase commit protocol of the distributed transaction that application 304 was executed in support of.
As such, the updated database entry 309c is forwarded from the cache 306 to the database 302. Note that the process of
Upon notice 16 of the committed message 15, the persistent data management service causes 17 a message to be sent 18 to the enqueue server 303 that causes the enqueue server 303 to remove the lock on the database entry. At this point, other applications will be allowed to gain access to the database entry.
The isolation level of
As a consequence, in response to the indication 1 that the application 404 desires access to the database entry, the persistent data management service 405 simply causes a read command 7 (e.g., in an SQL format) for the database entry to be sent to the database 402 (by communicating 6 to the resource manager 408).
The database 402 provides 8 the desired database entry 409a, which is subsequently loaded 9 into cache 406. The persistent database management service 405 is then able to respond to the application's initial request 1 by providing 10 the desired database entry 409a. At some later time the application may process the data 410 and cause it to be restored in cache 11 as database entry 409b. If the database entry 409b is updated by the application's processing 410 so as to contain one or more different values than it did prior to the application's processing 410, the persistent data management service causes 12 a message to be sent to the enqueue server 403 that commands the enqueue server to lock the database entry 13.
Here, note that another application may or may not have obtained access to the database entry in the time period between the read command 7 for the database entry on behalf of the application 404 and the receiving of the lock message by the enqueue server 13. If another application has not requested access to the database entry there is no issue—the database entry is locked by the enqueue server 403 for the use of application 404. If another application has requested access to the database entry, there exists “a race to lock”. That is, the first application to reach the enqueue server 403 with a lock message is deemed the owner of the database entry that is being competed for. All later competing applications that outright request to read or write to the database entry or request a lock on the database entry are somehow informed that the database entry is presently not available for use.
If a “race to lock” exists, in one embodiment, the enqueue server 403 either sends a favorable response to the locking message 13 if the application 404 is the first to request a lock; or, sends an “exception” message (or some other form of rejection) in response to the locking message 13 if the application 404 is not the first to request a lock (for ease of drawing, neither the favorable response nor the exception message are observed in
The remainder of the discussion of
As such, the updated database entry 409c is forwarded from the cache 406 to the database 402. Note that the process of
Upon receipt of the “commit” command by the database 402, the database 402 responds with a “committed” message 16 indicating that the updated information has been successfully written into the database 402. Upon notice 17 of the committed message 16, the persistent data management service causes 18 a message to be sent 19 to the enqueue server 403 that causes the enqueue server 403 to remove the lock on the database entry. At this point, other applications will be allowed to gain access to the database entry.
The isolation level of
The database 502 provides 8 the desired database entry 509a, which is subsequently loaded 9 into cache 506. The persistent database management service 505 is then able to respond to the application's initial request 1 by providing 10 the desired database entry 509a. At some later time the application may process the data 510 and cause it to be restored in cache 11 as database entry 509b. The application 504 then continues to run until completion. The state of the database entry at the time of completion is illustrated as cached database entry 509c.
If at the time of the application's completion, the cached database entry 509c corresponds to updated information so as to contain one or more different values than it did as compared to its initial cached state 509a, the persistent data management service 505 causes 12 a message to be sent to the enqueue server 503 that commands the enqueue server to lock the database entry 13.
Here, note that another application may or may not have obtained access to the database entry in the time period between the sending of the read command 7 and the receiving of the lock message by the enqueue server 13. If another application has not requested access to the database entry there is no issue—the database entry is locked by the enqueue server 503 for the use of application 504. If another application has requested access to the database entry, there exists “a race to lock”. As discussed with respect to
Again, if a “race to lock” exists, in one embodiment, the enqueue server 503 either sends a favorable response to the locking message 13 if the application 504 is the first to request a lock; or, sends an “exception” message (or some other form of rejection) in response to the locking message 13 if the application 504 is not the first to request a lock (for ease of drawing, neither the favorable response nor the exception message are observed in
The remainder of the discussion of
The resource manger 508, in response, sends the updated database entry to the database 502 with a “prepare” command or equivalent 15. For illustrative ease, the database's “ready” response and the “commit” command that is sent to the database as part of the two-phase commit protocol's execution are not shown in
In considering the discussions of
It is also important to re-emphasize that the database entries 309, 409, 509 referred to in regard to the discussions of
By loading the first and second database entries together into cache, the persistent data management service would be able to quickly perform a lookup from the first database entry to the second database entry in emulating a relational database. Here, according to the isolation level technique of
It also warrants reemphasis that isolation levels may be articulated for different database entries and/or groups of database entries within a single application. In an embodiment, an application is configured to define an isolation level for database entries and/or groups of database entries that it uses. In another embodiment, the isolation level for specific database entries and/or groups of database entries are defined and respected globally across all applications. For example, a descriptor or some other attribute of a database entry defines its isolation level. The isolation level therefore “follows” its database entry across the various uses of it by different applications. Here, note that it is possible that for the request based locking scheme of
Regardless,
It is apparent that the first processing string 601-606 may correspond to either of the update based locking schemes disclosed in
The discussions above have been primarily directed to isolation levels for database entries. Recall that if the enqueue server receives a request to lock a database entry that is already locked, the enqueue should respond with an “exception” message that indicates the database entry is already locked.
A retry is a “re-attempt” in requesting access to a database entry. According to the methodology of
Successive loops through processes 702, 703, 705, 706, 708 continue until the maximum number of retries is reached or a request is accepted. If a request is accepted 703, execution is completed with the database entry. Here, if the isolation level is that as described with respect to
If the maximum number of retries is reached 706 the distributed transaction that desires access to the database entry is rolled back 707. In one embodiment, the methodology is controlled by the application. In another embodiment the methodology of
In various embodiments, a group of database entries are identified as being suitable for loading into cache from a database at approximately “the same time” as part of a read transaction from a database (i.e., a group of database entries are read as whole). Such instances can be used to define a same isolation level for each entry in the group. That is, groups of database entries that are to receive a same isolation level are identified from the fact that they are read from the database together.
Processes taught by the discussion above may be performed with program code such as machine-executable instructions which cause a machine (such as a “virtual machine”, general-purpose processor or special-purpose processor) to perform certain functions. Alternatively, these functions may be performed by specific hardware components that contain hardwired logic for performing the functions, or by any combination of programmed computer components and custom hardware components.
An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodies as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards, or other type of machine-readable media suitable for storing electronic instructions.
It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation).
In the foregoing specification, the invention has been described with reference to specific exemplary 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 as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6557082 | Josten et al. | Apr 2003 | B1 |
| 20040205066 | Bhattacharjee et al. | Oct 2004 | A1 |
| 20040267807 | Barabas et al. | Dec 2004 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20070162449 A1 | Jul 2007 | US |
