<?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-D4001895-09B9-5A47-BEE7-648FAB55F85B"><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. Transactions are supported by the commit and revert protocol. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>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"><image href="GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e573431_href.png" placement="inline"/></fig> <section><title>See also</title> <p> <xref href="GUID-79F39C97-75E8-5DB1-B976-8FE76E6E60C9.dita">Dictionary stores</xref> </p> <p> <xref href="GUID-C9D8D913-C65F-5A69-A606-30F59BFB38E2.dita">File stores</xref> </p> </section> </conbody></concept>