Claims
- 1. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, a waiting depth limited concurrency control method performed by said transaction manager and comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein said data processing system is a centralized system and locks granted by said transaction manager are shared or exclusive, said data structure being a directed graph describing a hierarchy of transactions waiting on other transactions for release of exclusive locks on portions of said database, and said real-valued function is a number of locks held by a transaction;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value.
- 2. The waiting depth limited concurrency control method recited in claim 1 further comprising the step of revising said directed graph by grouping together every collection of two or more transactions holding or waiting in parallel for a lock in compatible modes into a single "super-transaction" so that every node in said directed graph is either a single transaction or a super-transaction.
- 3. The waiting depth limited concurrency control method as recited in claim 1 wherein each transaction running on the system is time stamped with a starting time and said real-valued function is a length of time a transaction has been running computed from said starting time to a current time.
- 4. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, a waiting depth limited concurrency control method performed by said transaction manager and comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein there are at least two active transactions T' and T running on the data processing system with m and n transactions waiting on each, respectively, and m is greater than zero, and transaction T' makes a lock request that conflicts with transaction T, and wherein said real-valued function is L and L(T) is a measure of a length of a transaction T;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value by testing to determine if L(T').gtoreq.L(T) and if, for each i, L(T').gtoreq.L(Ti'), and if so, giving priority to transaction T' and restarting transaction T; otherwise, restarting transaction T'.
- 5. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by plurality of concurrently running transactions, a wait depth limited concurrency control method comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein there are at least two active transactions T' and T running on the data processing system with m and n transactions waiting on each, respectively, and m is equal to zero, and transaction T' makes a lock request that conflicts with a transaction T.sub.1 waiting on transaction T, and wherein said real-valued function is L and L(T) is a measure of a length of a transaction T;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value by testing to determine if L(T.sub.1).gtoreq.L(T) and L(T.sub.1).gtoreq.L(T'), and if so, restarting transaction T; otherwise, restarting transaction T.sub.1.
- 6. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, a wait depth limited concurrently control method comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein there are at least two active transactions T' and T running on the data processing system with m and n transactions waiting on each, respectively, and m is greater than zero, and transaction T' makes a lock request that conflicts with a transaction T.sub.1 waiting on transaction T, and wherein said real-valued function is L and L(T) is a measure of a length of a transaction T;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value by testing to determine if L(T.sub.1).gtoreq.L(T.sub.1) and, for each i, if L(T').gtoreq.L(T.sub.i '), and if so, giving priority to transaction T' and restarting transaction T.sub.1 ; otherwise restarting transaction T'.
- 7. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, a waiting depth limited concurrency control method comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein there are at least two active transactions T' and T running on the data processing system with m and n transactions waiting on each, respectively, and m is greater than zero, and transaction T' makes a lock request that conflicts with a transaction T, and wherein said real-valued function is L and L(T) is a measure of a length of a transaction T;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value by testing to determine if L(T').gtoreq.L(T) and, for each i, if L(T').gtoreq.L(T.sub.i '), and if so, giving priority to transaction T' and restarting transaction T; otherwise restarting transaction T';
- but if m is equal to zero, and transaction T' makes a lock request that conflicts with a transaction T.sub.1 waiting on transaction T, then testing to determine if L(T.sub.1).gtoreq.L(T) and L(T.sub.1).gtoreq.L(T'), and if so, restarting transaction T; otherwise, restarting transaction T.sub.1 ;
- but if m is greater than zero, and transaction T' makes a lock request that conflicts with a transaction T.sub.1 waiting on transaction T, then testing to determine if L(T').gtoreq.L(T) and, for each i, if L(T').gtoreq.L(T.sub.i '), and if so, giving priority to transaction T' and restarting transaction T; otherwise restarting transaction T'.
- 8. In a multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, a waiting depth limited concurrency control method performed by said transaction manager and comprising the steps of:
- maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction, wherein said data processing system is a distributed system having a plurality of nodes, each of said nodes having a transaction manager including a local concurrency control and a global concurrency control and each transaction executes as a number of communicating subtransactions running concurrently at different ones of said nodes, said local concurrency controls managing locks and wait relations for subtransactions executing at their respective nodes and said global concurrency controls managing all wait relations that include any transaction with their respective node;
- for each request for a lock by a transaction, testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value;
- using said real-valued function to determine which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value; and
- restarting said subset of transactions so that the wait depth is reduced or kept to no more than said predetermined value, said global concurrency control making global restart decisions for any of the transactions in their set of wait relations.
- 9. The waiting depth limited concurrency control method as recited in claim 8 wherein said local concurrency control performs the steps of:
- processing each lock request using local lock tables and then determining if a first transaction is scheduled to wait on a second transaction;
- for each first transaction scheduled to wait on a second transaction as a result of processing a lock request, determining if said first and second transaction are running on a same node in said system; and
- for those first transactions scheduled to wait on a second transaction at the same node, sending the global concurrency control at said node a message that said first transaction is waiting on said second transaction.
- 10. The waiting depth limited concurrency control method as recited in claim 9 wherein said first and second transactions are not at the same node in the system, said local concurrency control further performs the steps of:
- sending a message to the global concurrency control of a node on which said first transaction is running that said first transaction is waiting on said second transaction; and
- sending a message to the global concurrency control of a node on which said second transaction is running that said first transaction is waiting on said second transaction.
- 11. The waiting depth limited concurrency control method as recited in claim 10 wherein said global concurrency control performs the step of upon receiving a message that a first transaction is waiting on a second transaction, updating a local table of a global wait directed graph to reflect the message, said global concurrency control then determining whether to restart transactions to maintain said wait depth to no more than said predetermined value.
- 12. The waiting depth limited concurrency control method as recited in claim 11 wherein each transaction running on the system is time stamped with a starting time and said real-valued function is a length of time a transaction has been running computed from said starting time to a current time.
- 13. The wait depth limited concurrency control method recited in claim 8 wherein said data structure is a directed graph describing a hierarchy of transactions waiting on other transactions for release of exclusive locks on portions of said database, and said real-valued function is a number of locks held by a transaction.
- 14. The wait depth limited concurrency control method recited in claim 13 further comprising the step of revising said directed graph by grouping together every collection of two or more transactions holding or waiting in parallel for a lock in compatible modes into a single "super-transaction" so that every node in said directed graph is either a single transaction or a super-transaction.
- 15. The waiting depth limited concurrency control method as recited in claim 8 wherein each transaction running on the system is time stamped with a starting time and said real-valued function is a length of time a transaction has been running computed from said starting time to a current time.
- 16. A multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, wherein said data processing system is a centralized system and locks granted by said transaction manager are shared or exclusive, said transaction manager implementing a waiting depth limited concurrency control and comprising:
- means for maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction;
- means for testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value for each request for a lock by a transaction;
- means for determining which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value using said real-valued function, said data structure being a directed graph describing a hierarchy of transactions waiting on other transactions for release of exclusive locks on portions of said database, and said real-valued function is a number of locks held by a transaction; and
- means for restarting said subset of transactions so that the depth is reduced or kept to no more than said predetermined value.
- 17. The waiting depth limited concurrency control method recited in claim 16 further comprising the step of revising said directed graph by grouping together every collection of two or more transactions holding or waiting in parallel for a lock in compatible modes into a single "super-transaction" so that every node in said directed graph is either a single transaction or a super-transaction.
- 18. The waiting depth limited concurrency control method as recited in claim 16 wherein each transaction running on the system is time stamped with a starting time and said real-valued function is a length of time a transaction has been running computed from said starting time to a current time.
- 19. A multi-user data processing system having a transaction manager including lock tables for managing accesses to a database by a plurality of concurrently running transactions, wherein said data processing system is a distributed system having a plurality of nodes, each of said nodes having a transaction manager including a local concurrency control and a global concurrency control and each transaction executes as a number of communicating subtransactions running concurrently at different ones of said nodes, said transaction manager implementing a waiting depth limited concurrency control and comprising:
- means for maintaining a wait depth data structure which graphically describes a waiting depth of transactions being processed by said system where, for each transaction in the system at any instant of time, a real-valued function provides a measure of a current length of a transaction;
- means for testing the wait depth data structure to determine if said waiting depth exceeds a predetermined value for each request for a lock by a transaction;
- means for determining which subset of transactions is to be restarted in case of a conflict between transactions which results in said waiting depth exceeding said predetermined value using said real-valued function, said local concurrency controls managing locks and wait relations for subtransactions executing at their respective nodes and said global concurrency controls managing all wait relations that include any transaction with their respective node; and
- means for restarting said subset of transactions so that the depth is reduced or kept to no more than said predetermined value, said global concurrency control making global restart decisions for any of the transactions in their set of wait relations.
- 20. The wait depth limited concurrency control method recited in claim 19 wherein said data structure is a directed graph describing a hierarchy of transactions waiting on other transactions for release of exclusive locks on portions of said database, and said real-valued function is a number of locks held by a transaction.
- 21. The waiting depth limited concurrency control method recited in claim 20 further comprising the step of revising said directed graph by grouping together every collection of two or more transactions holding or waiting in parallel for a lock in compatible modes into a single "super-transaction" so that every node in said directed graph is either a single transaction or a super-transaction.
- 22. The waiting depth limited concurrency control method as recited in claim 19 wherein each transaction running on the system is time stamped with a starting time and said real-valued function is a length of time a transaction has been running computed from said starting time to a current time.
CROSS-REFERENCE TO RELATED APPLICATION
This application is a continuation-in-part application of application Ser. No. 07/294,334 filed Jan. 5, 1989, by the applicants of this application and entitled "Wait Depth Limited Concurrency Control Method" abandoned.
US Referenced Citations (7)
Non-Patent Literature Citations (3)
Entry |
Date, "An Introduction to Database Systems vol. II", Addison-Wesley Publishing Co., 1983, pp. 83-100. |
Lorin et al., "Operating Systems", Addison-Wesley Publishing Co., 1984, pp. 91-92. |
"Encyclopedia of Computer Science and Engineering", Ralston et al.-Editors, Van Nostrand Reinhold Co., pp. 1532-1535. |
Continuation in Parts (1)
|
Number |
Date |
Country |
Parent |
294334 |
Jan 1989 |
|