diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita --- a/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita Wed Mar 31 11:11:55 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita Fri Jun 11 12:39:03 2010 +0100 @@ -1,52 +1,52 @@ - - - - - -Introduction -to TransactionsA transaction is a series of operations on a store, normally completed -by committing them using the store's CommitL() function. -

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.

-

If a leave occurs during an operation on the store during a transaction, -or if the store's RevertL() 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.

-

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.

-

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.

-

In permanent file stores the protocol applies to:

- -

The protocol also applies to creating new streams or replacing existing -streams in dictionary stores.

-

The protocol does not apply to overwriting existing streams.

-

The following diagram shows the idea:

- -Transaction Commit and Revert - - - -Dictionary -stores + + + + + +Introduction +to TransactionsA transaction is a series of operations on a store, normally completed +by committing them using the store's CommitL() function. +

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.

+

If a leave occurs during an operation on the store during a transaction, +or if the store's RevertL() 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.

+

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.

+

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.

+

In permanent file stores the protocol applies to:

+
    +

  • generating new streams

    • +

  • deleting streams

    • +

  • creating new streams

    • +

  • replacing streams

    • +

  • setting the root stream

    • +
+

The protocol also applies to creating new streams or replacing existing +streams in dictionary stores.

+

The protocol does not apply to overwriting existing streams.

+

The following diagram shows the idea:

+ +Transaction Commit and Revert + + + +Dictionary +stores \ No newline at end of file