VersaCloud's Transactions Operational Data Handling
Operational data is the name we use for the set of information our cloud-based time-limited transaction manager has to maintain while transactions are alive: they have been allowed to start (through an '…Allow' API call that returned an operation handle), but have not yet ended (that is, neither the corresponding '…Commit' API call has been executed neither the transaction's time-to-die has been reached). Once transactions are ended (successfully or not), most of the operational data gets stored in the call log. However, not only is access to information for alive transactions far more critical, but there are some possible states which do not make sense once a transaction is already 'part of history'.
That's why our finite state automaton was designed to store this information as a separate kind of state information, we have named as the 'pending transaction queue'. The pending transaction queue contains information for each API call that is part of each transaction already started, but not yet ended. Figure 15 depicts a snapshot of sample data from the pending transaction queue while running a 'MethodAdd…' transaction, defined in our API as part of creating methods.
The pending transaction queue, as can be seen in Figure 15, stores three 'blocks' of information about transactions. The first block is used to identify the transaction, by storing its name (as used in the corresponding API call) as well as its operation handle. Also time-to-die (as detailed together with our improved time-limited transaction concept) and the rollback status are part of this first information block. The rollback flag, marked as zero in the sample data, is used to signal transactions once their deletion process starts: before being 'history', some cleanup operations might be needed (as, for example, processing rollback callbacks, already explained as part of callbacks).
The second block of information is related to transaction billing: its cost and the user (or group) that is being charged for it, are stored in the pending transaction queue, so that in case the transaction has to be cancelled, we can reimburse that amount correctly. If the transaction succeeds, this same information gets into the call log.
Finally, the third block of information stores each calls actual parameter values, as defined by each API call. The only exception applies to parameter values of Type password: password values are replace by an informational notice (refer to the message '(passwords aren't logged)' in Figure 15, on the last line) immediately after the password has been validated. By doing so, we warrant that no developer, auditor, or any other user with special rights can access user's passwords, both in the pending transaction queue as well as in the call log.
US Patent Requested