<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-A278C1A2-0724-5800-B353-46809C44C142" xml:lang="en"><title>Transactions
on store databases</title><shortdesc>Atomicity of updates, roll backs, and what happens to indexes when
a rollback happens are covered in this document.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The store database, <codeph>RDbStoreDatabase</codeph>, runs completely
client side and requires the user program to provide a store for its operations.
For this reason, isolation, concurrency and serializability are not issues
for the transaction model. However, support for multiple rowsets concurrently
updating the same table is provided, and the rowset cursors attempt to maintain
their current position through such (potentially conflicting) updates.</p>
<p>Transactions on a store database do guarantee atomicity of updates. As <codeph>RDbStoreDatabase</codeph> is
designed to be a small-scale relational database, it does not make sense for
it to use transaction systems more suited to large server hosted databases.
Instead of using a logfile, the store database provides transaction support
by using the commit and revert functionality of <codeph>CStreamStore</codeph>.
If the actual store class does not support this protocol, then it cannot be
used as a basis for a DBMS store database. Practically, this means that store
databases are permanent file stores, i.e. <codeph>CPermanentFileStore</codeph>.</p>
<p>Successful transaction support by <codeph>RDbStoreDatabase</codeph> requires
that <i>the client must not call </i> <codeph>CommitL()</codeph> <i> and </i> <codeph>Revert()</codeph> <i> on
the store while the database is open</i>. Should a client need to modify its
own stream data using the store's commit/revert protocol while a database
is open, it can enclose the stream operations within a database transaction,
using rollback on error; this achieves an equivalent result. Such store operations
can be combined with database updates within a transaction to ensure that
the separate updates are treated atomically.</p>
<p>Committing a transaction leaves all open rowsets in a valid state. How
and when updates are reflected within those rowsets depends on how they have
been evaluated. </p>
<p>Rolling back a transaction causes all rowsets on the database to lose their
current place. All rowsets must be reset and possibly be re-evaluated before
they can be used again. However, they do not need to be opened or prepared
again.</p>
<p>Indexes cannot be recovered easily on rollback, so they are marked as unusable,
and the database is marked as damaged. Tables and untouched indexes continue
to operate as before. Recovering the database restores the damaged indexes
fully. </p>
<p>For multiple updates, explicitly using a transaction can also reduce the
time required by a factor of more than 50. It also reduces the transient store
size requirement by a factor of more than 6 — compaction of the store results
in similar sizes for updates whether or not a transaction was used.</p>
</conbody></concept>