VersaCloud's reentrancy restrictions

Reentrancy restrictions are the final sub-element of our improved transaction concept: our cloud-based time-limited transaction manager defines three types of conditions under which calling the same API for a second time in a certain period of time might be rejected by our single entry point engine. The two first types of restrictions are time-based, while the third type of restriction is based on (part of) the API's parameter values. Implementation of all of them is based on the API call log.

The first type of reentrancy restriction is a global minimum recalling time interval, defined for each API call. If any API which has this kind of restriction is called again, by any user, before this minimum time interval has passed since the previous call, our cloud-based time-limited transaction manager's single entry point engine rejects the call. This kind of restriction is useful to protect back-end servers from an excessive number of calls, when their processing capability is limited (or only limited capability is exposed to cloud-based interactions).

For example, if the back-end server administrator only wants (or the server itself is only able) to handle ten calls per second, then the minimum recalling time should be set at hundred milliseconds; when a second call to this same API is received by our single entry point engine before this hundred milliseconds have passed (since the previous call to the same API), it gets rejected and the back-end server is not involved in any way.

To 'Get' or 'Set' this first type of restriction for a specific API call, the 'MethodMinimumDelayGet', 'MethodMinimumDelaySetAllow' and 'MethodMinimumDelaySetCommit' APIs must be called.

The second type of reentrancy restriction is a per user minimum recalling time interval, limiting each individual user's capacity to call a specific API twice in a period of time. This time interval can be related or not to the first type of reentrancy restriction.

For example, a back-end server might limit each user to being serviced by calling an API only once every thirty seconds (for security reasons), although the back-end server is able to serve thousands or millions of users per second (and having a low or no global recalling restriction).

To 'get' or 'set' this second type of restriction for a specific API call, the 'MethodMinimumDelayPerUserGet', 'MethodMinimumDelayPerUserSetAllow' and 'MethodMinimumDelayPerUserSetCommit' APIs must be called.

The third and final type of reentrancy restriction is based on the API call's parameter values. Each parameter defined for an API call can be defined as being part (or not) of the reentrancy key. This concept is similar to the primary key of a relational database table, in two aspects: first, recalling key parameters are a subset of the set of all API's parameters, in the same way as the primary key columns are a subset of the set of columns of a relational table; second, in the same way as relational tables cannot contain two rows with the same values in the primary key columns, our single entry point engine does not allow for a second call of an API with same values as recalling key parameters while another call to the same API is in progress using the same parameter values.

For example, the 'UserAddAllow' API (called to add new users to the transaction manager's set of users) takes various parameters as input (including the user's full name, birth date and others) but only the user's e-mail is marked as a member of the reentrancy key. Hence, once the transaction to add a specific user has started (coming from any front-end software running on any device), no second call to start adding the same user will be accepted by our transaction manager's single entry point engine, unless the first one reaches its time-to-die (or has ended successfully).

On the other hand, note that value-based reentrancy restrictions are not always desirable: for example, the 'UserLoginAllow' API call (used to warrant user login to our transaction manager by receiving his e-mail and password) doesn't have any value-based restrictions – this way, the same user can login from many different end-user software at the same time (running various instances on a single device and/or various software on different devices).

To 'Get' or 'Set' these value-based reentrancy restrictions for a specific API, the API calls 'MethodParameterReentrancyKeyMemberGet', 'MethodParameterReentrancyKeyMemberSetAllow' and 'MethodParameterReentrancyKeyMemberSetCommit' are available.

US Patent Requested