Transactions and locking

More than one client can concurrently share information in the database without fear of it being changed while in use. CommDb uses the concept of transactions to implement this, making use of the underlying DBMS mechanism to set the necessary locks.

Within a transaction, a client can safely read records without fear that those records may be changed between successive read operations. A client can also, safely, make changes to the database within a transaction.

The CCommsDatabaseBase class provides three member functions which provide the necessary support for transactions:

• BeginTransaction()

• CommitTransaction()

• RollbackTransaction()

BeginTransaction() marks the beginning of a transaction: it tries to get a shared read-lock on the database. Other clients can also get a shared read-lock on the database allowing them to read records concurrently

Once a client has a shared read-lock, any subsequent operation by that client which attempts to write to the database will attempt to upgrade the shared read-lock to an exclusive write-lock on the database; this succeeds only if no other client already has a lock on the database. This behaviour is provided by the underlying DBMS.

CommitTransaction() marks the end of the transaction committing any changes to the table: it unlocks the database, removing the client's shared read-lock if no write operations were performed, or the exclusive write-lock if write operations were performed.

RollbackTransaction() marks the end of the transaction but abandons any changes made since the call to BeginTransaction(): it unlocks the database, removing the client's shared read-lock if no write operations were performed, or the exclusive write-lock if write operations were performed.