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