VersaCloud's time-limited transactions

In order to avoid this incomplete garbage transactions overload, VersaCloud systematically uses an improved version of the relational transaction concept (compare with the cloud-based time-limited transaction concept: we replace program-based 'rollback' operations by time-limited transactions. Instead of leaving the decision to declare success or failure through programming logic, every transaction is defined to succeed only in a maximum predefined period of time (which can be one second, half an hour or any predefined amount of time).

Hence, if the maximum time allowed for a transaction has passed, our server can 'slaughter' the transaction's data automatically. So, programming logic is required only to communicate success. When a transaction is started by calling the 'MethodInvokeAllow' API, the duration parameter defines the maximum time allowed, which we call the transaction's 'time to live' in our documentation.

Our single entry point engine adds 'time to live' to the current time in order to compute what we call the 'time to die' for each specific transaction. Any request related to a transaction received after its 'time to die' has been reached, will be rejected by our single entry point engine, and the caller will receive a specific error code. As resources used to handle the transaction on our cloud-based middleware server are freed once 'time to die' has been reached, we avoid the problems traditional transaction managers face on the cloud. The process of automatically rollbacking 'died' transactions and freeing the resources they used is handled by a background job running once per second on our cloud-based middleware server (if configured to do so, back-end servers get alerts for each dying transaction).

Our cloud-based time-limited transaction concept is the basis of VersaCloud, and is used as wide as possible: even user login is treated as a transaction (started by a call to the 'UserLoginAllow' API) that has a maximum duration equivalent to the time the user will remain logged in. If the user wants to logoff before that maximum time specified, the login transaction just gets committed by the programming logic inside the front-end software by calling the 'UserLoginCommit' API.

US Patent Requested