Collapse all Symbian^3 Application Developer Library

 

This topic describes the purpose of transactions when accessing the Comms Database.

The CommsDat API provides the behaviour known as transactions. Tools and applications use transactions to make sure that read and write operations are consistent.

More than one application can use the Comms Database at the same time. Transactions implement a lock that allows applications to perform a set of read and write operations safely. In a transaction, other applications cannot change the data.

The CMDBSession class provides the functions that implement transactions.

You must create a session with the Comms Database before you start your first transaction.

A transaction starts with a call to CMDBSession::OpenTransactionL() , and ends with a call to CMDBSession::CommitTransactionL() or CMDBSession::RollbackTransactionL() .

A call to CMDBSession::OpenTransactionL() starts a transaction.

A call to CMDBSession::CommitTransactionL() or CMDBSession::RollbackTransactionL() ends a transaction.

Between the start and end of a transaction, the CommsDat API makes sure that:

• a write operation started by another session cannot interrupt a read operation or a read/write operation started by this session.

• all read/write operations succeed after a succesful call to CMDBSession::CommitTransactionL() .

• all read/write operations are discarded after a successful call to CMDBSession::RollbackTransactionL() /

• the changes are visible only to the tool or application that started the transaction. To the tool or application, the changes appear to have been written to the Comms Database.

• other users of the Comms Database cannot see the changes made by a transaction until that transaction is committed.

The CommsDat API cannot make other guarantees. Tools and applications must not make assumptions about the lock mechanism used by the implementation of the Comms Database.

Tools and applications must make sure that transactions are short. The Comms Database is a shared resource, and long transactions cause performance problems. The Comms Database implements a timeout to protect the database. The Comms Database can terminate very long transactions. The timeout does not affect the normal operation.

It is more efficient to wrap several write operations in one transaction, because data is only written to the Comms Database in a call to CMDBSession::CommitTransactionL() . Tools and applications must not hold a transaction open for longer than is necessary.

All read and write functions provided by MMetaDatabase use transactions internally and are consistent.