--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-A278C1A2-0724-5800-B353-46809C44C142.dita	Wed Mar 31 11:11:55 2010 +0100
@@ -0,0 +1,52 @@
+<?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>
\ No newline at end of file