In terms of BridgeWorX64 transactions, hibernation refers to the act of taking a long-running transaction and temporarily removing it from the execution queue so that other transactions can be processed.
The BridgeWorX64 engine has a certain number of threads for executing transactions. This essentially represents the number of transactions that BridgeWorX64 can have executing at one time. BridgeWorX64 also has a queue of transactions waiting to be executed.
We can imagine that our transactions are shoppers, the queue of waiting transactions is a line or queue at the grocery store, and the execution threads are the checkout cashiers. Every cashier can handle only one customer at a time. When a cashier is done, they call the next customer from the queue.
Let’s say we have six cashiers. If one of those customers getting checked out takes an extremely long time because they must do a price check on one of their items, then there are only five cashiers left to take customers from the queue. This can become a big problem if a lot of customers must do price checks. All the cashiers could become stuck with waiting customers. Customers with only a small basket may have to wait for a long time behind cashiers who are doing nothing while someone runs to do a price check.
The solution to this problem is to save the transaction so far and have the customer waiting for the price check move off to the side until the price check is done. This frees up the cashier to begin working on another customer. When the price check is finished, the customer waiting off to the side will be taken by the next available cashier.
Transaction hibernation is how we temporarily move long running transactions out of the execution threads so that quicker transactions don’t have to wait.
Transactions with a configured delay activity will be hibernated if the delay time is fixed and exceeds a preconfigured threshold.
When a transaction execution thread (a cashier, in our earlier metaphor) is available, it will first check to see if any hibernated transactions are ready to begin executing again. If they are, the transaction is awoken and executed.
Transactions being awoken do not go back into the queue. They are given priority over enqueued transactions. (Cashiers process customers who are done with their price checks before they take a new customer from the line.)
This threshold is configured in Workbench on the transaction object (under the Bridging > Transactions > your configuration). It is in the Advanced Settings section and named Dehydration Threshold. This is the only setting that must be configured to take advantage of hibernation.
Note: Later betas or the releases will have this field renamed to “Hibernation Threshold.” “Dehydration” was an old name for this feature.
Transactions that have long delay periods benefit the most from hibernation. Take this example.
Assume that we have a transaction that performs the following actions:
Reads a value from a tag.
Waits 1 minute.
Writes a value to a tag.
A burst of 25 instances of this transaction are triggered at one time. BridgeWorX64 is configured to process six concurrent transactions at a time.
Without transaction hibernation, this set of 25 transactions will take approximately 5 minutes to fully complete. Six transactions will be taken out of the queue and processed. Each transaction will read its tag, wait one minute, then write its tag. This will take 1 minute. When they are done, six more will be executed for another minute, etc.
With transaction hibernation, all 25 transactions will be done in a little over a minute. Six transactions will be taken out of the queue and read their first tag, but when they reach the 1-minute block they will be hibernated. Another six will be taken out of the queue and read their tag. In this way, all 25 transactions will read their tag and be hibernated very quickly. A minute later, six transactions will be awoken and write to their tag, followed by six more, etc. until all 25 have written to their tag.
By hibernating the transactions at the delay action, we process the delays in parallel, rather than sequentially, allowing us to complete more transactions in less time.
Transaction Hibernation Comparisons
See Also: