Describes 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:
calling Begin() (a
member of RDbDatabase) on a shared database attempts to get
a shared read-lock on the database; this fails if any other client
already has an exclusive write-lock. Other clients with read-locks will not
cause this operation to fail.
any operation which
modifies the database, tries to gain an exclusive write-lock on it; this fails
if any other client has any kind of lock on that database. If the current
client already has a read-lock as a result of calling Begin(),
then the lock is upgraded to an exclusive write-lock.
calling Commit() or Rollback() after
a read-lock has been acquired (but not a write-lock) releases the client's
lock. The database is only considered to be unlocked when all such
locks are removed by all clients, when it will report a RDbNotifier::EUnlock database
event to any change notifier.
calling Commit() or Rollback() after
a write-lock has been acquired releases the client's lock and reports a RDbNotifier::ECommit or
a RDbNotifier::ERollback database event to any change notifier.
automatic transactions are used if updates are made outside of explicit transactions; such updates can also fail if an exclusive lock cannot be acquired.
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.