DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed 06/16/2025 has been entered. Claims 1, 10-11, and 17 have been amended. Claims 7 and 16 have been cancelled. Claims 1-6, 8-15, and 17-20 remain pending in the application.
Response to Arguments
Claim Rejections - 35 USC §103
Regarding the newly amended claim 1 Applicant argues that “Dice describes "a multiprocessor environment with threads and preemptive scheduling, threads can participate in a mutual exclusion protocol through the use of lock or "mutex" constructs." Dice, paragraph [0004]. Dice states that "the lock implementation may include a counter whose value reflects the number of times that the lock is passed between threads executing on a single NUMA node and this counter may be incremented each time the lock is passed between threads executing on a single NUMA node." Dice, paragraph [0098]. However, none of the other asserted references teach "determine a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the distributed database system [and] adjust the batch size associated with the first node based on the number of transactions of the first set of transactions that have been executed at the first node and the number of times that the exclusive node-lock has been exchanged between the first node and the second node," as recited in claim 1. “.
In response, Examiner relies on a new combination of references.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8, 10-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over CHU (US 2018/0181187 Al ) in view of Menendez (US 11,347,712 B2) in further view of Brassow (US 2011/0191561 Al )
Regarding claim 1, CHU discloses: A system, comprising: a storage device configured to store a batch size associated with a first node of a plurality of nodes (CHU [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size; [0021] a relational database is installed in the storage unit 110, and the relational database records related information of many financial accounts; [0004] An on-line transaction processing system (OLTP system) utilizes relational databases to process and/or analyze millions of daily transactions.)
and one or more processors in communication with the storage device configured to: execute a first set of transactions at the first node while an exclusive node-lock has been set for the first node; (CHU [0031] before updating the batch of update information (step S35), the processing unit 140 can lock the identification data corresponding to the batch of update information in advance, namely, the processing unit 140 can restrict the transaction events of the identification data (step S34). In addition, during updating (corresponding to “a first set of transactions”)the financial data corresponding to the batch of update information with the batch of update information, the corresponding identification data are retained in a locked state;[0025] Then, the processing unit 140 executes batch updates of the financial data of the same identification data according to a batch size and the transaction data (step S30); [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
detect that a number of transactions of the first set of transactions that have been executed at the first node is less than the batch size; (CHU, [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373); [0030] when the number of the received transaction data is 10,000 and the current batch size is 500, the processing unit 140 retrieves the 1st transaction data to the 500th transaction data from the received transaction data as a batch of update information (a first batch of update information), and executes an updating of financial data corresponding to the batch of update information with the batch of update information. When the updating of the batch of update information is completed, the processing unit 140 adjusts the batch size according to the current processing state of the updating (i.e., the updating time and the first time threshold; [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
and adjust the batch size associated with the first node based on the number of transactions of the first set of transactions that have been executed at the first node (CHU [0030] when the number of the received transaction data is 10,000 and the current batch size is 500, the processing unit 140 retrieves the 1st transaction data to the 500th transaction data from the received transaction data as a batch of update information (a first batch of update information), and executes an updating of financial data corresponding to the batch of update information with the batch of update information. When the updating of the batch of update information is completed, the processing unit 140 adjusts the batch size according to the current processing state of the updating (i.e., the updating time and the first time threshold; [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
However CHU does not clearly disclose:
a plurality of nodes of a distributed database system; detect that a request for the exclusive node-lock for a second node of the plurality of nodes has been received while the first set of transactions is executed at the first node; detect that a number of transactions of the first set of transactions that have been executed at the first node is less than the batch size; determine a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the distributed database system; and adjust the batch size associated with the first node based on the number of transactions of the first set of transactions that have been executed at the first node and the number of times that the exclusive node-lock has been exchanged between the first node and the second node. However Menendez discloses:
detect that a request for the exclusive node-lock for a second node of the plurality of nodes has been received while the first set of transactions is executed at the first node; (Menendez, column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled.)
detect that a number of transactions of the first set of transactions that have been executed at the first node is less than the batch size; (Menendez, column 13, line 12- minimum number of records is less than the commit count (corresponding to “batch size”), resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending; column 15, line 8- This commit count will be used by the transactional VSAM engine to determine when and if to issue a commit point on behalf of the records utilized by a batch application, such as by calling resource recovery services (RRS);column 1, line 43- The method also includes receiving, at the job control manager, a commit count associated with the batch application…line 53- the method includes committing, in response to the batch application having completed processing of an nth record of the group of records, all records of the group of records that are locked resulting from execution of the batch application. In this embodiment, n is equal to the commit count)
and adjust the batch size associated with the first node based on the number of transactions of the first set of transactions that have been executed at the first node. (Menendez, column 1, line 43- The method also includes receiving, at the job control manager, a commit count (corresponding to “batch size”) associated with the batch application…line 53- the method includes committing, in response to the batch application having completed processing of an nth record of the group of records, all records of the group of records that are locked resulting from execution of the batch application. In this embodiment, n is equal to the commit count ; column 15, lines 5- 17, e.g. The transactional VSAM engine may adjust the commit frequency (number of records accessed and/or record locks requested) to a value between the minimum and maximum values based on an analysis of the number of pending record locks (waiters) in the current transaction or unit of recovery (UR); column 13, line 12- minimum number of records is less than the commit count (corresponding to “batch size”), resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending;)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
However CHU in view of Menendez does not clearly disclose: a plurality of nodes of a distributed database system; determine a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the distributed database system; and the number of times that the exclusive node-lock has been exchanged between the first node and the second node.
However Brassow discloses:
a plurality of nodes of a distributed database system;
(Brassow, Fig. 1; [0037] distributed database; [0032], e.g. the machine may be connected ( e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer ( or distributed) network environment.)
determine a number of times that the exclusive node-lock has been exchanged between the first node and the second node, (Brassow , Fig. 3; [0011], e.g. The exclusive acquisition of the lock can be monitored by way of
counters. A distributed locking manager (DLM) can be utilized in one embodiment as the inter-machine locking mechanism. The DLM provides a range of shared and exclusive
locking modes, as well as a way to utilize a small amount of inter-machine shared memory. The small amount of intermachine shared memory can be used to store a global counter. The global counter is incremented before an exclusive lock is
released. This global counter is used to compare against a local, non-shared counter that is not updated when another machine acquires an exclusive lock, but is updated when the local machine acquires either an exclusive or shared lock (signaling the intent of the local machine to either modify or read the resource))
the first node and the second node comprise two different nodes of the distributed database system; (Brassow, Fig. 1; [0037] distributed database; [0032], e.g. the machine may be connected ( e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer ( or distributed) network environment.)
and the number of times that the exclusive node-lock has been exchanged between the first node and the second node. (Brassow , Fig. 3; [0011], e.g. The exclusive acquisition of the lock can be monitored by way of
counters. A distributed locking manager (DLM) can be utilized in one embodiment as the inter-machine locking mechanism. The DLM provides a range of shared and exclusive
locking modes, as well as a way to utilize a small amount of inter-machine shared memory. The small amount of intermachine shared memory can be used to store a global counter. The global counter is incremented before an exclusive lock is
released. This global counter is used to compare against a local, non-shared counter that is not updated when another machine acquires an exclusive lock, but is updated when the local machine acquires either an exclusive or shared lock (signaling the intent of the local machine to either modify or read the resource))
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU in view of Menendez with the teaching of Brassow to coordinate the access of shared resources in a tightly-coupled cluster that includes a number of processing system, (Brassow, abstract), and also to facilitate the elimination of unnecessary cache validation work, (Brassow, [0010]).
Regarding claim 2, CHU in view of Menendez in further view Brassow of discloses all of the features with respect to claim 1 as outlined above. Claim 2 further recites: the one or more processors are configured to increase the batch size in response to detection that the number of transactions of the first set of transactions is less than the batch size. (CHU [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373); [0034] On the other hand, when the processing system 10 is free (i.e., when the updating time is less than the first time threshold), the updating size (the batch size) can be increased slightly.)
However CHU does not clearly disclose:
the number of transactions of the first set of transactions is less than the batch size
However Menendez discloses:
the number of transactions of the first set of transactions is less than the batch size (Menendez, column 13, line 12- minimum number of records is less than the commit count (corresponding to “batch size”), resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending; column 15, line 8- This commit count will be used by the transactional VSAM engine to determine when and if to issue a commit point on behalf of the records utilized by a batch application, such as by calling resource recovery services (RRS);column 1, line 43- The method also includes receiving, at the job control manager, a commit count associated with the batch application…line 53- the method includes committing, in response to the batch application having completed processing of an nth record of the group of records, all records of the group of records that are locked resulting from execution of the batch application. In this embodiment, n is equal to the commit count)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
Regarding claim 3, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. Claim 3 further recites: the number of transactions of the first set of transactions that have been executed at the first node is less than all of the first set of transactions. (CHU [0030] For example, when the number of the received transaction data is 10,000 and the current batch size is 500, the processing unit 140 retrieves the 1st transaction data to the 500th transaction data from the received transaction data as a batch of update information (a first batch of update information), and executes an updating of financial data corresponding to the batch of update information with the batch of update information.)
Regarding claim 4, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. Claim 4 further recites: wherein: the one or more processors are configured to: execute a third set of transactions at the first node while the exclusive node-lock has been set for the first node; (CHU [0031] before updating the batch of update information (step S35), the processing unit 140 can lock the identification data corresponding to the batch of update information in advance, namely, the processing unit 140 can restrict the transaction events of the identification data (step S34). In addition, during updating the financial data corresponding to the batch of update information with the batch of update information, the corresponding identification data are retained in a locked state)
CHU does not clearly disclose:
detect that each transaction of the third set of transactions was executed at the first node prior to detection that a second request for the exclusive node-lock for the second node was received; and decrease the batch size associated with the first node in response to detection that each transaction of the third set of transactions was executed prior to detection that the second request for the exclusive node-lock for the second node was received.
However Menendez discloses:
detect that each transaction of the third set of transactions was executed at the first node prior to detection that a second request for the exclusive node-lock for the second node was received; (Menendez, column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled.)
and decrease the batch size associated with the first node in response to detection that each transaction of the third set of transactions was executed prior to detection that the second request for the exclusive node-lock for the second node was received. (Menendez, column 13, line 12- minimum number of records is less than the commit count, resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending; column 15, line 5- the new parameter (commit count) may include a minimum value and a maximum value that specifies a range of values for record lock and record access requests. This commit count will be used by the transactional VSAM engine to determine when and if to issue a commit point on behalf of the records utilized by a batch application, such as by calling resource recovery services (RRS). The transactional VSAM engine may adjust the commit frequency (number of records accessed and/or record locks requested) to a value between the minimum and maximum values based on an analysis of the number of pending record locks (waiters) in the current transaction or unit of recovery (UR);)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
Regarding claim 5, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. Claim 5 further recites: the one or more processors are configured to cause the exclusive node-lock for the first node to be released upon detection that a second number of transactions of the first set of transactions equal to the batch size have been executed at the first node. (CHU [0031] after the updating of the financial data corresponding to the batch of update information with the batch of update information is completed, the processing unit 140 releases the locked identification data ( step S36). In other words, in the case that the identification data is in the locked state, when the processing unit 140 receives transaction data of the locked identification data from other external device (hereinafter called additional transaction data), the processing unit 140 does not execute the updating of the corresponding financial data according to the additional transaction data; [0006] The processing unit executes batch updates of the financial data of the same identification data according to a batch size and the transaction data.)
Regarding claim 6, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. CHU does not clearly disclose: the one or more processors are configured to determine an amount of reduction in the batch size based on a number of times that transactions executed by the first node have completed execution prior to receiving an exclusive node-lock request for the second node.
However Menendez discloses:
the one or more processors are configured to determine an amount of reduction in the batch size based on a number of times that transactions executed by the first node have completed execution prior to receiving an exclusive node-lock request for the second node. (Menendez, column 15, line 12- The transactional VSAM engine may adjust the commit frequency (number of records accessed and/or record locks requested) to a value between the minimum and maximum values based on an analysis of the number of pending record locks (waiters) in the current transaction or unit of recovery (UR); column 13, line 12- minimum number of records is less than the commit count (corresponding to “batch size”), resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending;)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
Regarding claim 8, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. Claim 8 further recites: the one or more processors are configured to adjust the batch size associated with the first node based a network latency for a network over which messages are transmitted to the first node. (CHU, [0010] dynamically adjust the batch size or the power configuration or other system parameters according to external environmental dynamic factors (like network, hardware performance, etc.).)
Regarding claim 10, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 1 as outlined above. CHU in view of Menendez does not clearly disclose: the plurality of nodes corresponds with nodes of the distributed database system.
However Brassow discloses:
the plurality of nodes corresponds with nodes of the distributed database system. (Brassow, Fig. 1; [0037] distributed database; [0032], e.g. the machine may be connected ( e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer ( or distributed) network environment.)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU in view of Menendez with the teaching of Brassow to coordinate the access of shared resources in a tightly-coupled cluster that includes a number of processing system, (Brassow, abstract), and also to facilitate the elimination of unnecessary cache validation work, (Brassow, [0010]).
Regarding claim 11, CHU discloses: A method for operating a database system, comprising: initiating execution of a first set of transactions at a first node of the database system while an exclusive node-lock has been set for the first node ; (CHU [0031] before updating the batch of update information (step S35), the processing unit 140 can lock the identification data corresponding to the batch of update information in advance, namely, the processing unit 140 can restrict the transaction events of the identification data (step S34). In addition, during updating (corresponding to “a first set of transactions”)the financial data corresponding to the batch of update information with the batch of update information, the corresponding identification data are retained in a locked state;[0025] Then, the processing unit 140 executes batch updates of the financial data of the same identification data according to a batch size and the transaction data (step S30); [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
determining a batch execution time for the first set of transactions; (CHU, [0006] The timer unit counts an updating time; [0007] adjusting the batch size of a next batch update according to the updating time and a time threshold of the batch of update information. [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373).
detecting that the batch execution time for the first set of transactions is less than a threshold batch execution time for the first node (CHU, [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373).)
and adjusting the threshold batch execution time for the first node in response to detecting that the batch execution time for the first set of transactions is less than the threshold batch execution time for the first node. (CHU, [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373).)
CHU does not clearly disclose:
detecting that a request for the exclusive node-lock for a second node of the database system has been received during execution of the first set of transactions at the first node; detecting that the batch execution time for the first set of transactions is less than a threshold batch execution time for the first node in response to detection that the request for the exclusive node-lock for the second node has been received; determining a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the database system; and the number of times that the exclusive node-lock has been exchanged between the first node and the second node.
However Menendez discloses:
detecting that a request for the exclusive node-lock for a second node of the database system has been received during execution of the first set of transactions at the first node; (Menendez, Fig. 1B; column 6, lines 47-55; column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled.)
detecting that the batch execution time for the first set of transactions is less than a threshold batch execution time for the first node in response to detection that the request for the exclusive node-lock for the second node has been received; (Menendez, column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled; column 13, lines 11-16; column 14, lines 1-8, determination that the quantity of record lock requests will be processed prior to a shortest timeout thereof after completing the processing of the mth record of the second group of records.)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
However CHU in view of Menendez does not clearly disclose: determining a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the database system; and the number of times that the exclusive node-lock has been exchanged between the first node and the second node.
However Brassow discloses:
determining a number of times that the exclusive node-lock has been exchanged between the first node and the second node, (Brassow, Fig. 3; [0011], e.g. The exclusive acquisition of the lock can be monitored by way of
counters. A distributed locking manager (DLM) can be utilized in one embodiment as the inter-machine locking mechanism. The DLM provides a range of shared and exclusive
locking modes, as well as a way to utilize a small amount of inter-machine shared memory. The small amount of intermachine shared memory can be used to store a global counter. The global counter is incremented before an exclusive lock is
released. This global counter is used to compare against a local, non-shared counter that is not updated when another machine acquires an exclusive lock, but is updated when the local machine acquires either an exclusive or shared lock (signaling the intent of the local machine to either modify or read the resource))
the first node and the second node comprise two different nodes of the database system; (Brassow, Fig. 1; [0037] distributed database; [0032], e.g. the machine may be connected ( e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer ( or distributed) network environment.)
and the number of times that the exclusive node-lock has been exchanged between the first node and the second node. (Brassow , Fig. 3; [0011], e.g. The exclusive acquisition of the lock can be monitored by way of
counters. A distributed locking manager (DLM) can be utilized in one embodiment as the inter-machine locking mechanism. The DLM provides a range of shared and exclusive
locking modes, as well as a way to utilize a small amount of inter-machine shared memory. The small amount of intermachine shared memory can be used to store a global counter. The global counter is incremented before an exclusive lock is
released. This global counter is used to compare against a local, non-shared counter that is not updated when another machine acquires an exclusive lock, but is updated when the local machine acquires either an exclusive or shared lock (signaling the intent of the local machine to either modify or read the resource))
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU in view of Menendez with the teaching of Brassow to coordinate the access of shared resources in a tightly-coupled cluster that includes a number of processing system, (Brassow, abstract), and also to facilitate the elimination of unnecessary cache validation work, (Brassow, [0010]).
Regarding claim 12, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 11 as outlined above. Claim 12 further recites: the adjusting the threshold batch execution time for the first node includes increasing the threshold batch execution time for the first node based on a time difference between the batch execution time and the threshold batch execution time. (CHU [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373).)
Regarding claim 13, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 11 as outlined above. Claim 13 further recites:
releasing the exclusive node-lock for the first node after the threshold batch execution time has elapsed; (CHU [0031] Next, after the updating of the financial data corresponding to the batch of update information with the batch of update information is completed, the processing unit 140 releases the locked identification data ( step S36); [0007] Wherein, the step of executing each of the batch updates comprises obtaining a batch of update information from the transaction data according to a current batch size; driving a timer unit to count an updating time; updating a batch of financial data in the financial data corresponding to the batch of update information with the batch of update information; and adjusting the batch size of a next batch update according to the updating time and a time threshold of the batch of update information.)
CHU in view of Menendez does not clearly disclose:
and transmitting an acknowledgment to the second node that the second node has acquired the exclusive node-lock.
However Brassow discloses:
and transmitting an acknowledgment to the second node that the second node has acquired the exclusive node-lock. (Brassow [0017]-[0018], e.g. [0017] after the lock location is determined, the requesting machine sends a lock request to the lock managing machine to acquire the lock. In response, the lock managing machine returns an indication of success (lock acquired) or failure (lock acquisition failed) to the requesting machine; [0023], e.g. 2) success, indicating some other machine or machines have grabbed the lock exclusively while the lock is held in the MONITOR mode, or 3) success, indicating no one else has acquired the lock exclusively
while the lock was held in the MONITOR mode)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU in view of Menendez with the teaching of Brassow to coordinate the access of shared resources in a tightly-coupled cluster that includes a number of processing system, (Brassow, abstract), and also to facilitate the elimination of unnecessary cache validation work, (Brassow, [0010]).
Regarding claim 14, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 11 as outlined above. Claim 14 further recites: initiating execution of a third set of transactions at the first node while the exclusive node-lock has been set for the first node; (CHU [0031] before updating the batch of update information (step S35), the processing unit 140 can lock the identification data corresponding to the batch of update information in advance, namely, the processing unit 140 can restrict the transaction events of the identification data (step S34). In addition, during updating the financial data corresponding to the batch of update information with the batch of update information, the corresponding identification data are retained in a locked state)
detecting that an amount of time that the third set of transactions has been executing is greater than the threshold batch execution time for the first node;
and decreasing the threshold batch execution time for the first node in response to detecting that the amount of time that the third set of transactions has been executing is greater than the threshold batch execution time for the first node. (CHU [0032] after the updating of the batch of update information is completed, the processing unit 140 compares the updating time consumed by the batch of update information with the first time threshold (step S370) to determine if the updating time exceeds the first time threshold (step S371). When the updating time is greater than the first time threshold (i.e., the updating time exceeds lower limit of the first time threshold, that represents the batch of update information still have data that are not updated when the updating has lasted for the first time threshold), the processing unit 140 decreases the batch size of the next batch update (step S372).)
CHU does not clearly disclose:
detecting that a second request for the exclusive node-lock for the second node has been received while executing the third set of transactions at the first node;
However Menendez discloses:
detecting that a second request for the exclusive node-lock for the second node has been received while executing the third set of transactions at the first node;
(Menendez, column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled.)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
Regarding claim 15, CHU in view of Menendez in further view Brassow discloses all of the features with respect to claim 14 as outlined above. CHU does not clearly disclose:
the decreasing the threshold batch execution time for the first node includes determining an amount of reduction in the threshold batch execution time based on a number of times that transactions executed by the first node have completed execution prior to receiving an exclusive node-lock request for the second node.
However Menendez discloses:
the decreasing the threshold batch execution time for the first node includes determining an amount of reduction in the threshold batch execution time based on a number of times that transactions executed by the first node have completed execution prior to receiving an exclusive node-lock request for the second node.
(Menendez, column 15, line 12- The transactional VSAM engine may adjust the commit frequency (number of records accessed and/or record locks requested) to a value between the minimum and maximum values based on an analysis of the number of pending record locks (waiters) in the current transaction or unit of recovery (UR); column 13, line 12- minimum number of records is less than the commit count, resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending;)
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CHU with the teaching of Menendez to preventing long running transactions from holding record locks, (Menendez, column 3, line 24).
Regarding claim 17, CHU discloses: A method for operating a database system, comprising: executing a first batch of transactions at a first node of the database system while a node-lock for a page has been set for the first node; (CHU [0031] before updating the batch of update information (step S35), the processing unit 140 can lock the identification data corresponding to the batch of update information in advance, namely, the processing unit 140 can restrict the transaction events of the identification data (step S34). In addition, during updating (corresponding to “a batch of transactions”)the financial data corresponding to the batch of update information with the batch of update information, the corresponding identification data are retained in a locked state;[0025] Then, the processing unit 140 executes batch updates of the financial data of the same identification data according to a batch size and the transaction data (step S30); [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
detecting that a number of transactions of the first batch of transactions that have been executed at the first node is less than a batch size for the first node; (CHU, [0032] When the updating time is less than the first time threshold (i.e., the updating time exceeds the first time threshold, that represents the batch of update information is already updated before the updating lasted for the first time threshold), the processing unit 140 increases the batch size of the next batch update (step S373); [0030] when the number of the received transaction data is 10,000 and the current batch size is 500, the processing unit 140 retrieves the 1st transaction data to the 500th transaction data from the received transaction data as a batch of update information (a first batch of update information), and executes an updating of financial data corresponding to the batch of update information with the batch of update information. When the updating of the batch of update information is completed, the processing unit 140 adjusts the batch size according to the current processing state of the updating (i.e., the updating time and the first time threshold; [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
and adjusting the batch size for the first node based on the number of transactions of the first batch of transactions that have been executed at the first node. (CHU [0030] when the number of the received transaction data is 10,000 and the current batch size is 500, the processing unit 140 retrieves the 1st transaction data to the 500th transaction data from the received transaction data as a batch of update information (a first batch of update information), and executes an updating of financial data corresponding to the batch of update information with the batch of update information. When the updating of the batch of update information is completed, the processing unit 140 adjusts the batch size according to the current processing state of the updating (i.e., the updating time and the first time threshold; [0026] the processing unit 140 obtains a number of transaction data from the transaction data stored in the register unit 130 as a batch of update information, and the number of the transaction data is the current batch size.)
However CHU does not clearly disclose:
detecting that a second node of the database system has requested the node-lock for the page during execution of the first batch of transactions at the first node; detecting that a number of transactions of the first batch of transactions that have been executed at the first node is less than a batch size for the first node; determining a number of times that the exclusive node-lock has been exchanged between the first node and the second node, the first node and the second node comprise two different nodes of the database system; and adjusting the batch size for the first node based on the number of transactions of the first batch of transactions that have been executed at the first node and the number of times that the exclusive node-lock has been exchanged between the first node and the second node.
However Menendez discloses:
detecting that a second node of the database system has requested the node-lock for the page during execution of the first batch of transactions at the first node; (Menendez, column 12, line 19- discovering the existence and tracking a quantity of record lock requests that are pending execution due to the batch application processing the group of records…line 33- These pending record lock requests are issued by one or more devices (physical or virtual device(s) that is/are different from the job control manager as it executes method 400) to lock at least one record and/or access at least one record that is already locked due to execution of the batch application, and therefore are pending and have not been fulfilled.)
detecting that a number of transactions of the first batch of transactions that have been executed at the first node is less than a batch size for the first node; (Menendez, column 13, line 12- minimum number of records is less than the commit count (corresponding to “batch size”), resulting in a technique that allows for early committing (prior to processing an amount of records equal to the commit count) to deal with the record lock requests that are pending; column 15, line 8- This commit count will be used by the transactional VSAM engine to determine when and if to issue a commit point on behalf of the records utilized by a batch application, such as by calling resource recovery services (RRS);column 1, line 43- The method also includes receiving, at the job control manager, a commit count associated with the batch application…line 53- the method includes committing, in response to the batch application having completed processing of an nth record of the group of records, all records of the group of records that are locked resulting from execution of the batch application. In t