The Row Reservation Mechanism

One of the more complicated issues in Distributed SQL is the problem of avoiding data collisions when different clients add row data into distributed tables.

The problem arises when at least two clients (say A and B) both add a row of data to a given table (perhaps a Customer table). Clearly, it would be possible for both A and B to add a row to the "end" of the table, say row X. Both rows are distributed to the Primary Server (approximately simultaneously) and one of the two updates is lost.

To prevent this from happening, each of the clients requests a row reservation set from the Primary Server. In the case above, client A may perhaps receive reservations on rows X, X+1, ..., X+9 (depending on table configuration). Client B may then receive reservations X+10, X+11, ..., X+19. These row reservations function exactly the same as the reservation of a seat at the cinema. When you have seat 3 reserved, no-one else may sit there. Analogously, client A may use row X for its new customer, while client B will use row X+10. The clash is avoided.

When a client runs out of row reservations on a given table, the Distributed Client automatically triggers a request for a new row reservation set from the Primary Server, and further processing is delayed until this row reservation set arrives (typically a couple of milliseconds).

Independent processing

If the client is connected to the Primary Server via the Internet, there may on occasion be loss of connection to the server. For a conventional database client, this is fatal. In the case of a Distributed Client, however, local processing is usually able to continue.

Obviously queries to the local database may be performed without problem. Adding data, though, looks to be more problematic. However, due to the row reservation mechanism, the client is still able to add several rows of data before processing has to wait for the server to furnish a new row reservation set.

If interruptions of service are commonplace, the configuration of tables with high addition rates may be modified to provide larger reservation sets - perhaps 100 or even more. With appropriate configuration, the user may not even be aware of data link interruptions.

Once the link to the server is restored, the Distributed Client will automatically re-establish connection to exactly the same session as before the interruption. Pending data will be transmitted to the Primary Server, and the server will of course transmit any pending updates from other clients to the re-connnected Distributed Client. Everything continues as before.