Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Transactions and locks

When multiple clients can access the same database, transactions ensure that only one client can change data at a time.

DBMS transactions do not provide any form of isolation between clients; while one client is updating a table within a transaction, other clients can see the changes as they are made. For example, if a client retrieves two separate rows from a database, there is no automatic guarantee that the data being retrieved has not been changed between the reads; this can lead to an ‘inconsistent read’. A client can prevent an update while retrieving related rows by enclosing the individual reads within a transaction. Such a transaction does not modify the database and only operates as a read-lock; the Commit() or Rollback() member functions of the abstract base class RDbDatabase releases such a lock and does not affect the database in any way.

In practice:

Sharing read-locks enables greater concurrency while providing some safe guard against inconsistent reads. However, there is the possibility of a deadlock occurring. If two clients want to update a database and both Begin() a transaction before either of them starts an update, then one client's read-lock will prevent the other from upgrading to a write lock and vice versa. The only way out of this is to code the clients in such a way as to back out of such a deadlock situation, rather than retry forever without releasing the locks.

To prevent a single transaction from containing both data modification and data definition statements, all affected cursors are invalidated when the definition of their underlying table is changed. Such a cursor reports a KErrDisconnected error in this state and can only be closed and the rowset re-generated once the DDL (SQL schema update) statement has completed. Calling Reset() on such a cursor has no effect. It is impossible to update rows while changing the schema.

A client can change the database schema while other clients are using that database provided that they have no locks on it. However, those other clients may find that their rowsets are invalidated asynchronously.