Transactions and Consistency

Understand how Airport implements transactional consistency and read isolation for Arrow Flight servers using transaction identifiers.

The Airport extension interacts primarily with external systems, which may not provide the same transactional guarantees as native DuckDB tables. However, Airport implements mechanisms to support consistency and transactional semantics where possible.

Consistency of Reads

In database systems, data consistency ensures that transactions see a stable, accurate view of data, even when concurrent modifications occur.

Airport supports read consistency through transaction identifiers:

  1. At the start of a transaction, Airport invokes a DoAction RPC with the create_transaction action.
  2. The server returns an optional unique transaction identifier.
  3. This identifier is included in all subsequent RPCs via the airport-transaction-id gRPC header.
  4. Servers that respect this identifier can ensure consistent data views within the same transaction, even across multiple tables.

Server Responsibilities:

  • Data accessed with the same transaction identifier must be consistent across all tables and requests
  • Servers must reject expired or invalid transaction identifiers by raising an Arrow Flight exception
  • This mechanism enables reliable, consistent data access even when querying remote systems

Commit and Rollback

Airport-managed tables differ from native DuckDB tables in their transactional behavior:

Current Behavior:

  • Data modifications (INSERT, DELETE, UPDATE) are sent immediately to the Arrow Flight server
  • The server is expected to commit changes during the RPC request
  • This differs from traditional SQL transactions that defer commits until an explicit COMMIT statement

Error Handling:

  • If the server cannot commit the data, it must raise an Arrow Flight exception
  • This exception causes the DuckDB transaction to abort
  • Clients can catch and handle these exceptions appropriately
Note

Future versions of Airport may introduce deferred commit semantics, allowing servers to participate in two-phase commit protocols or handle rollbacks more gracefully.