|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B" xml:lang="en"><title>Introduction |
|
13 to Transactions</title><shortdesc>A transaction is a series of operations on a store, normally completed |
|
14 by committing them using the store's <codeph>CommitL()</codeph> function. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>Transactions are supported by the commit and revert protocol. The series |
|
16 of operations forming a transaction must all succeed for the transaction to |
|
17 be successful. </p> |
|
18 <p>If a leave occurs during an operation on the store during a transaction, |
|
19 or if the store's <codeph>RevertL()</codeph> function is called explicitly, |
|
20 the transaction is reverted. This facility parallels the commit and rollback |
|
21 functions which are conventional in databases. However, reverting is not quite |
|
22 the same as rolling back; integrity of data is guaranteed, but some indexes |
|
23 may be corrupted. </p> |
|
24 <p>The commit and revert protocol is useful for ensuring that persistent data |
|
25 moves from one consistent state to another and for guaranteeing the integrity |
|
26 of persistent store data in the event of failures. </p> |
|
27 <p>Typically, changes to a store are not made permanent until they are committed, |
|
28 establishing what is called a commit point. Until such changes are committed, |
|
29 they can be rolled back or reverted, effectively causing the store to revert |
|
30 back to its state before the changes were made. If a process termination or |
|
31 a media failure occurs, the store reverts automatically to its state at the |
|
32 last successful commit point. </p> |
|
33 <p>In permanent file stores the protocol applies to: </p> |
|
34 <ul> |
|
35 <li id="GUID-F16D4A25-8103-563C-9DC5-D79F7C275ACB"><p>generating new streams </p> </li> |
|
36 <li id="GUID-A0EA4352-D06B-59D3-9E04-D0B42131AF5B"><p>deleting streams </p> </li> |
|
37 <li id="GUID-83307858-E18D-5F78-8E30-F6754EB6926E"><p>creating new streams </p> </li> |
|
38 <li id="GUID-FAD15660-6405-5C11-A72D-40471D5FE2E5"><p>replacing streams </p> </li> |
|
39 <li id="GUID-A00822E2-2FE7-55CA-9144-7B9F6DA7C3F7"><p>setting the root stream </p> </li> |
|
40 </ul> |
|
41 <p>The protocol also applies to creating new streams or replacing existing |
|
42 streams in dictionary stores. </p> |
|
43 <p>The protocol does<i> not</i> apply to overwriting existing streams. </p> |
|
44 <p>The following diagram shows the idea: </p> |
|
45 <fig id="GUID-9F093A25-C9C6-5590-9427-EBC4BD26AC73"> |
|
46 <title>Transaction Commit and Revert</title> |
|
47 <image href="GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e361851_href.png" placement="inline"/> |
|
48 </fig> |
|
49 </conbody><related-links> |
|
50 <link href="GUID-79F39C97-75E8-5DB1-B976-8FE76E6E60C9.dita"><linktext>Dictionary |
|
51 stores</linktext></link> |
|
52 </related-links></concept> |