<?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>