Much of the Bayou model can be explained by its use for a meeting room scheduler whose purpose is to facilitate reserving meeting rooms when the requestors have agreed upon a room and a set of acceptable times. At most, one person can reserve the room for any given period. Users interact with a UI that shows the schedule of a room along with the times it is already reserved. A user simply selects an available time to reserve it but because she may be requesting a time that might have already been reserved by someone else and does not show up on her display, she has the choice to select several available times instead of just one. Eventually one of them will be reserved. A reservation may remain “tentative” for a while.  In this stage, it may be rescheduled as other conflicting reservations become known.

Data is persisted in the form of a data collection that is replicated in full at several servers. Applicants running as clients interact with the servers through the Bayou API.  There are two basic operations supported: Read and Write. Read is for queries and write is for inserting, modifying, and deleting data items. Access to one server is sufficient for a client to perform useful work.

A Bayou write is processed with the input parameters of the update to perform, a dependency check supplied by the application and a merge procedure also supplied by the application. The process evaluates the dependency check to see whether the actual differs from the expected result. If there is a mismatch, it evaluates the merge-procedure to determine the resolved update otherwise the resolved update is the given update. The resulting update is then applied to the storage.

A Bayou write consists of an update that originates from a form filled in by the meeting room scheduling user who provides the datetime, duration and purpose of a new reservation request. It also consists of a dependency check that involves a SQL like query such as Select key from meetings where day is the given day, and the time lies between a start and an end with the expected result to be an empty data set. It consists of a merge procedure that takes different alternatives for time slots and for each choice, check if there would be a conflict by running the dependency check like query for the time slot of that alternative and skipping it when there is a conflict or creating a new update and breaking out of the looping over the alternatives. If no alternative is acceptable, the new update is tentatively the one user provided and the write operation returns the resulting update.

When applying a set of Bayou writes to the database, the system must check if the set of writes originated from the user or from another server. When the write is received from a client, the server’s virtual timestamp is incremented, and the write is inserted at the end of the write log with the state as tentative. Then the Bayou write is invoked with the parameters as this record, the dependency check and the merge procedure. In the case of the write set originating from another server, the append and the timestamp increment order is opposite to that of the sequence for the write set originating from the user. The write set is ordered, and the insertion point is determined, which is also the point recorded to rollback to in the form of a tuple store and the write inserted. Each write after the insertion point is then rolled forward by applying the Bayou write with that record, the dependency check, and the merge procedure. The logical clock for the server’s closure is recorded.