Flip Documentation LibraryFlip Internal Design

Flip Internal Design

• About Flip Internal Design
• Commit Cycle
• The Transaction Stack
  • Overview
  • Acknowledged Transaction
  • Denied Transaction
  • External Transaction
  • Conflict Management
  • Batches
• Opcode

The Transaction Stack

This chapter describes the transaction stack of a flip Document.

Overview

Each flip document has a transaction stack. This stack contains transactions that needs to be acknowledged or denied by the server.

As a client pull the flip document and receive information from the server, the transaction stack will manage the control flow of the flip document and will prune transactions are they are acknowledged or denied. It also manages external transactions coming from other clients (and also other documents on the local host, but this is not exposed here first for simplicity).

The transaction stack has in particular, two important properties :

• When the stack is in its normal state, the flip document is in the client document state,
• When the stack is in its rollbacked state, the flip document is in the last known server document state.

The following sections describe how the transaction stack is managed during 3 scenarios :

• When a transaction is acknowledged by the server,
• When a transaction is denied by the server,
• When an external transaction, that is a transaction from another user, is received from the server.

In all cases, the general concept and algorithm is the same :

1. Rollback to be in the same state as the server,
2. Execute the command received by the server,
3. Put back the transaction stack in its normal state

The following will describe those operations in the 3 scenarios.

Acknowledged Transaction

When the client does not use multiple document with a Hub, then the first transaction on the transaction stack is always the one acknowledged by the server.

In this case there is no need to rollback, execute the acknowledged transaction, drop it and then reexecute the rest of the transaction stack, since this all operation is identity.

Instead, the first transaction of the transaction stack is dropped, as an optimisation.

When the client uses multiple document with a Hub, then the first transaction might be one of a document on a local host. A check is done to see if the first transaction matches the one acknowledged and in this case, the transaction is dropped. In other cases, the transaction stack is rollbacked before executing the acknowledged transaction, and then the acknowledge transaction is removed from the transaction stack.

Denied Transaction

The transaction stack is rollbacked to be in the same state as the server, then the denied transaction is dropped from the transaction stack without being executed, and then the rest of the transaction stack is executed.

External Transaction

The transaction stack is rollbacked to be in the same state as the server, then the external transaction is executed, and then the whole transaction stack is executed again.

Conflict Management

The situation can arise where an external transaction is received and executed, but then the other transactions from the transaction stack cannot be applied anymore. This is in particular the case when a conflict is going to occur.

In this case, the faulty transactions are marked as non-executed, and they won't be executed also when rollbacking the transaction stack.

Batches

In practice, the transaction stack operation might be batched, for example if the pull operation receives multiple commands from the server. In this case the rollback and reexecution of the transaction stack are kept to a minimum.