<?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-D4001895-09B9-5A47-BEE7-648FAB55F85B" xml:lang="en"><title>Introduction
to Transactions</title><shortdesc>A transaction is a series of operations on a store, normally completed
by committing them using the store's <codeph>CommitL()</codeph> function. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Transactions are supported by the commit and revert protocol. The series
of operations forming a transaction must all succeed for the transaction to
be successful. </p>
<p>If a leave occurs during an operation on the store during a transaction,
or if the store's <codeph>RevertL()</codeph> function is called explicitly,
the transaction is reverted. This facility parallels the commit and rollback
functions which are conventional in databases. However, reverting is not quite
the same as rolling back; integrity of data is guaranteed, but some indexes
may be corrupted. </p>
<p>The commit and revert protocol is useful for ensuring that persistent data
moves from one consistent state to another and for guaranteeing the integrity
of persistent store data in the event of failures. </p>
<p>Typically, changes to a store are not made permanent until they are committed,
establishing what is called a commit point. Until such changes are committed,
they can be rolled back or reverted, effectively causing the store to revert
back to its state before the changes were made. If a process termination or
a media failure occurs, the store reverts automatically to its state at the
last successful commit point. </p>
<p>In permanent file stores the protocol applies to: </p>
<ul>
<li id="GUID-F16D4A25-8103-563C-9DC5-D79F7C275ACB"><p>generating new streams </p> </li>
<li id="GUID-A0EA4352-D06B-59D3-9E04-D0B42131AF5B"><p>deleting streams </p> </li>
<li id="GUID-83307858-E18D-5F78-8E30-F6754EB6926E"><p>creating new streams </p> </li>
<li id="GUID-FAD15660-6405-5C11-A72D-40471D5FE2E5"><p>replacing streams </p> </li>
<li id="GUID-A00822E2-2FE7-55CA-9144-7B9F6DA7C3F7"><p>setting the root stream </p> </li>
</ul>
<p>The protocol also applies to creating new streams or replacing existing
streams in dictionary stores. </p>
<p>The protocol does<i> not</i> apply to overwriting existing streams. </p>
<p>The following diagram shows the idea: </p>
<fig id="GUID-9F093A25-C9C6-5590-9427-EBC4BD26AC73">
<title>Transaction Commit and Revert</title>
<image href="GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e355771_href.png" placement="inline"/>
</fig>
</conbody><related-links>
<link href="GUID-79F39C97-75E8-5DB1-B976-8FE76E6E60C9.dita"><linktext>Dictionary
stores</linktext></link>
</related-links></concept>