In horizontal fragmentation, we place different rows of a table between different sites within the distributed database. In vertical fragmentation, different sites have their own selection of columns for a table.

If after receiving the “commit-request” message, any site finds that it is not in a state to commit T — or if any site has become unavailable due to network or computer failure — then this protocol would end up where some sites have committed but others have not. This would violate atomicity in a rather ugly way.

Since a transaction can involve changes to data at multiple sites, all sites involved with a transaction must agree to an identical decision regarding whether the transaction should be committed: If one site cannot commit while another thinks it should, the transaction's atomicity would be violated. One site may not be able to commit due to some local failure (two possibilities are deadlock or a hardware error), and in that case all sites will need to make it so that the transaction had no effect.

In the first phase, the coordinator asks all sites whether they are ready to commit the transaction, and all sites respond. In the second phase, the coordinator decides whether the transaction will abort or commit, and it sends this decision to all involved sites.

It must query another site to determine the fate of the transaction. Once it determines the answer for the other site, it logs the answer into its own log.

Any transaction that requires a lock of the element will only be required to obtain the lock from any two of the three systems. If any is down, then of course it will request the lock from the remaining two systems. But it will never be that two transactions manage to obtain the same exclusive lock, since each transaction requires two sites to agree, and there are only three sites.

Here are three:

1. Support for aggregate types like sets, lists, and structs.
2. Methods can be associated with a row/object.
3. References allow for direct references between tuples — essentially pointers, except that the tuples are actually stored on disk.

A reference essentially behaves as a memory address describing a row in a table. (It does not in fact reference memory, since the database is stored on disk.) It allows one to have a table that includes direct references to rows in other tables. By contrast, in relational databases, a reference to a row in another table is stored indirectly, by listing the primary key values for that other table.

References allow a query such as the following, in which the SELECT clause includes an implicit lookup into an accounts table to identify the name associated with each account. With a relational DBMS, we would need to join the accounts and deposits tables.