Page Comparison

Die Abfolge der Operationen in einer Transaktion wird durch den Transaktionsgraph beschrieben. Der Transaktionsgraph ist ein endlicher Automat mit einem ausgezeichneten Startzustand und einem oder mehreren finalen Zuständen. Die Zustände werden mit Nummern von 1 bis 199 bezeichnet. Dabei gilt folgendes: Der Startzustand hat die Nummer 1, finale Zustände haben Nummern von 100 bis 199, alle anderen Zustände haben Nummern zwischen 2 und 99. Übergänge zwischen den einzelnen Zuständen erfolgen durch Operationen oder gegebenenfalls durch andere Ereignisse auf dem Server.

Wird eine Transaktion zwischen Client und Server durch entsprechendes Durchführen von Operationen realisiert, so wird dadurch eine Instanz der Transaktion konstituiert. Die Identität der Instanz wird gegeben durch die Identitäten von Käufer und Verkäufer, sowie eine vom Server generierte Zeichenkette, die TransactionID (vgl. RequestType, ResponseType). Zu einer Instanz gehört auch der Transaktionskontext: er umfasst die genannten Kennzeichner, den gegenwärtigen Zustand der Transaktion und mögliche weitere Daten, die durch die Operationen dieser Transaktionsinstanz modifiziert werden.

Falls der Server die Operationen GetStatus und Rollback unterstützt, kann ein Client zu jeder Transaktionsinstanz, an der er beteiligt ist, beim Server mittels der Operation GetStatus, den gegenwärtigen Zustand der Transaktion abfragen, und er kann die Transaktion mittels der Operation Rollback abbrechen, sofern sich die Transaktionsinstanz in einem Zustand befindet, der ein Rollback erlaubt. Ein finaler Zustand erlaubt grundsätzlich kein Rollback, beim Startzustand ist ein Rollback jederzeit möglich und völlig ohne Wirkung. Per Konvention ist bei Zuständen mit Nummer 2 bis 49 ein Rollback möglich, bei Nummer 50 bis 99 ist dies nicht möglich.

Es hat sich gezeigt, dass Clients typischerweise weder von der Operation GetStatus noch von der Operation Rollback Gebrauch machen. Daher sind diese Operationen seit veloconnect 1.3 optional.

Regel: Lebenszyklus einer Transaktionsinstanz

Eine Transaktionsinstanz durchläuft folgenden Lebenszyklus: Durch Ausführen einer der Operationen, die im Startzustand anwendbar sind, wird die Transaktionsinstanz gegebenfalls erzeugt. Sobald sich die Transaktionsinstanz in einem finalen Zustand befindet, steht der Transaktionskontext für eine neue Transaktionsinstanz zur Verfügung. Die Transaktionsinstanz existiert allerdings noch weiter, bis eines der folgenden Ereignisse auftritt:

• der Transaktionskontext wird für eine neue Transaktionsinstanz benötigt,

• eine implementierungsabhängige Zeitspanne, die mindestens 300 Sekunden beträgt, ist verstrichen.

Unabhängig vom Zustand kann der Server nach frühestens 2 Stunden nach der letzten durchgeführten Operation einen Rollback ausführen und die Transaktionsinstanz löschen.

Der Server sollte nicht davon ausgehen, dass der Client alle begonnenen Transaktionen zu Ende führt oder ein Rollback ausführtThe 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.