<?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 xml:lang="en" id="GUID-A278C1A2-0724-5800-B353-46809C44C142"><title>Transactions on store databases</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>As the store database, <codeph>RDbStoreDatabase</codeph>, runs completely client side and requires the user program to provide a store for its operations, 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, they must be reset and possibly 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>