Chapter 6. ACID Properties of Lb-server

This section explains the guarantees the lb-server database provides. We also highlight requirements for filesystem and hard-drives as well as necessary configuration options to achieve the described properties.

6.1. Atomicity

Transactions have an all or nothing property. Changes that are performed within a transaction are either applied and visible to future (or concurrent) transactions in their entirety or not at all. In particular, if a transaction aborts (due to a constraint violation), then non of the changes that were made within this transaction are visible to any other transaction or user of the database. In other words, at any time the observed state of a workspace is the result of a recently successfully committed transaction.

6.2. Consistency

The LogiQL language allows to define a wide variety of rules and constraints that describe how data in various predicates relates to each other. Rules include standard IDB rules, eg. that define returns[x] <- sales[x] - costs[x] and trigger or delta-rules, eg., +employee(x) <- +new_hire(x) to name the most common. Constraints include basic functional constraints, eg. in a functional predicate foo[x]=y there is at most one y for each x, as well as constraints that are explicitly formulated using "right-arrow" rules.

The lb-server ensures that a transaction only successfully commits if all rules and constraints from the active workspace state are satisfied. That means, at the end and the start of any transaction, the database is always in a consistent state. Transactions that would violate integrity constraints are aborted with an integrity violation message. Note that integrity violations are the only cause for aborted transactions. The unique concurrency model of the LogicBlox database never aborts otherwise valid transactions. This is for example, not the case for conventional optimistic concurrency models where transactions can be aborted due to concurrent behavior.

6.3. Isolation

The LogicBlox database guarantees the isolation level SERIALIZABLE. Currently, we support concurrently executing read-only transactions while write-transactions are serialized and executed one after another. Future releases will allow concurrent write-transactions while providing the same isolation level of SERIALIZABLE. In practice this means that application development is simplified: Even though transactions are processed concurrently the state changes between one transaction to the next can fully be explained by a serial execution. Thus, application developers need not to be concerned with potential anomalies that arise due to concurrency.

For example, a long-running read-only transaction T of, say 20 seconds, obtains a consistent state of the database when it is started. Now, during the evaluation of this transactions, other write transactions may modify the database state and even commit new versions--however, these modifications are not visible to T.

6.4. Durability

Transactions to the lb-server can be configured with softcommit or diskcommit. As described in Section 2.6, “Trouble Shooting” the two commit-modes differ only in the time when the lb-server reports to the client that the transaction has been finished. While for diskcommit we report SUCCESS only after the transaction has been written to disk, we already notify the client of a successful transaction once it is committed to the memory representation for softcommit transactions. In case of power failures, or kill -9, or similar events it is thus possibly that softcommited transactions are lost.

Note that the transaction throughput is not effected by the diskcommit vs. softcommit setting. We thus recommend using softcommit only for transactions that do not have strict durability requirements.

Hardware and OS Requirements for Durability

The durability mechanism of the LogicBlox database is based on versioned data structures and requires that once fsync has been called and has returned successfully, all outstanding requests to the file have been written to disk to non-volatile memory. It is important that the system administrator verifies that the software stack comprising hard-drive-firmware and kernel software guarantees that these requirements on fsync are satisfied. Many hard drives are for example "lying" to the operating system by using write-caches. Thus, even though the operating system assumes that data has been written to the non-volatile disk memory, the disk itself holds the data in volatile memory.

On Linux, hdparm -I /dev/disk_device can be used to check whether a write-cache is enabled for a certain device. Use hdparm -W to disable disk write-caches. It is also important to verify that all layers on top of the disk support fsync properly. These layers might include raid configurations (eg, hardware as well as software raids), logical volume managers (eg, LVM) and the used file system.


LogicBlox does perform write-ahead logging, but uses persistent data structures to provide its durability guarantees. It is thus not necessary to configure any write-ahead logging related parameters.

LogicBlox is resilient against partial writes, that is the database data cannot become corrupted if any write operation is aborted at any point in time. We require that the underlying mechanism does not reorder writes to a consecutively region of 144 bytes.