Transactions

The sequence of operations in a transaction is described by a transaction graph, a finite machine with an identifiable initial state and one or more final states. The states are denoted by numbers from 1 to 199, with the following applying here: The initial state has number 1, final states have numbers from 100 to 199, all other states have numbers between 2 and 99. Transitions between the individual states are effected by operations or, if necessary, other events on the server.

Realizing a transaction between the client and server through execution of the relevant operations results in an instance of that transaction. The identity of the instance is given by the identities of the buyer and seller, as well as a string generated by the server and known as transaction ID (see RequestType, ResponseType). An instance also encompasses the transaction context comprising the mentioned identifiers, the current state of the transaction, and possibly further data modified by the operations of that transaction instance.

If the server supports the GetStatus and Rollback operations, a client can request, in the case of each transaction instance in which it participates, the server for the transaction's current state using the GetStatus operation, and can cancel the transaction by means of the Rollback operation if the transaction instance is in a state allowing rollback. A final state never allows rollback, an initial state always allows rollback without any consequences whatsoever. By convention, a rollback is possible for states with numbers 2 to 49, but not possible with numbers 50 to 99.

It turns out that clients typically do not use either the GetStatus or Rollback operation. These operations have therefore been optional since Veloconnect 1.3.

Rule: Life cycle of a transaction instance

A transaction instance passes through the following life cycle: Executing one of the operations available in the initial state creates the transaction instance, if applicable. Once the transaction instance is in a final state, the transaction context is available for a new transaction instance. The transaction instance persists until one of the following events occurs:

• The transaction context is needed for a new transaction instance.

• An implementation-dependent time of at least 300 seconds has elapsed.

Regardless of state, the server can execute a rollback and delete the transaction instance no sooner than 2 hours after the last operation.

The server should not assume that the client completes all initiated transactions or implements a rollback.