Context of a Transaction - Firebird

A complete conversation between a client and the server is known as a transaction. Each transaction has a unique context that causes it to be isolated from all other transactions in a specific way. The rules for the transaction’s context are specified by the client application program, by passing transaction parameters. A transaction starts when a client signals the beginning of the transaction and receives a transaction handle back from the server. It remains active until the client either commits the work (if it can) or rolls it back.

One Transaction, Many Requests

In Firebird, every operation requested by a client must occur in the context of an active transaction. One transaction can entail one or many client requests and server responses within its bounds. A single transaction can span more than a single data- base, encompassing reads from and writes to multiple databases in the course of a task. Tasks that create databases or change their physical structure (single or batched DDL statements) entail transactions, too.Client and server each has its role:

  • Client role: Clients initiate all transactions. Once a transaction is under way, a client is responsible for submitting requests to read and write and also for completing (committing or rolling back) every transaction it starts. A single client connection can have multiple transactions active.
  • Server role: It is the job of the server to account for each transaction uniquely and keep each transaction’s view of database state consistent with its context. It has to manage all requests to change the database so that conflicts are handled appropriately and any risk of breaking the consistency of database state is pre-empted.

Figure broadly illustrates a typical read-write transaction context from start to finish. It shows how the server manages many concurrent transactions independently of all others, even if the other transactions are active in the same client application.

Transaction context and independence

Transaction context and independence

In this illustration, the application may use the transaction to select (read) sets of rows, any of which may be chosen by the user for updating or deleting. In the same transaction, new rows might be inserted. Update, insert, or delete requests are “posted” to the server, one by one, as the user performs her task.

Atomicity of the Model

The capability for a client application to issue multiple, reversible requests inside a single Firebird transaction has obvious advantages for tasks that need to execute a single statement many times with a variety of input parameters. It inherently provides atomicityfor tasks where a group of statements must be executed and, finally, either committed as a single job or rolled back entirely if an exception occurs.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Firebird Topics