|
||
Note: This section is provided as a reference for the legacy CommDb component, which has been superceded by the CommsDat component. It is strongly recommended that users migrate to CommsDat. For implementations using CommsDat, see Transactions in the CommsDat API and Migration Guide.
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.