12 <concept xml:lang="en" id="GUID-A278C1A2-0724-5800-B353-46809C44C142"><title>Transactions on store databases</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>As the store database, <codeph>RDbStoreDatabase</codeph>, runs completely client side and requires the user program to provide a store for its operations, isolation, concurrency and serializability are not issues for the transaction model. However, support for multiple rowsets concurrently updating the same table is provided, and the rowset cursors attempt to maintain their current position through such (potentially conflicting) updates.</p> <p>Transactions on a store database do guarantee atomicity of updates. As <codeph>RDbStoreDatabase</codeph> is designed to be a small-scale relational database, it does not make sense for it to use transaction systems more suited to large server hosted databases. Instead of using a logfile, the store database provides transaction support by using the commit and revert functionality of <codeph>CStreamStore</codeph>. If the actual store class does not support this protocol, then it cannot be used as a basis for a DBMS store database. Practically, this means that store databases are permanent file stores, i.e. <codeph>CPermanentFileStore</codeph>.</p> <p>Successful transaction support by <codeph>RDbStoreDatabase</codeph> requires that <i>the client must not call </i> <codeph>CommitL</codeph> <i>() and </i> <codeph>Revert</codeph> <i>() on the store while the database is open</i>. Should a client need to modify its own stream data using the store's commit/revert protocol while a database is open, it can enclose the stream operations within a database transaction, using rollback on error; this achieves an equivalent result. Such store operations can be combined with database updates within a transaction to ensure that the separate updates are treated atomically.</p> <p>Committing a transaction leaves all open rowsets in a valid state. How and when updates are reflected within those rowsets depends on how they have been evaluated. </p> <p>Rolling back a transaction causes all rowsets on the database to lose their current place, they must be reset and possibly re-evaluated before they can be used again: however, they do not need to be opened or prepared again.</p> <p>Indexes cannot be recovered easily on rollback, so they are marked as unusable, and the database is marked as damaged. Tables and untouched indexes continue to operate as before. Recovering the database restores the damaged indexes fully. </p> <p>For multiple updates, explicitly using a transaction can also reduce the time required by a factor of more than 50. It also reduces the transient store size requirement by a factor of more than 6 — compaction of the store results in similar sizes for updates whether or not a transaction was used.</p> </conbody></concept>

    12 <concept id="GUID-A278C1A2-0724-5800-B353-46809C44C142" xml:lang="en"><title>Transactions

    13 on store databases</title><shortdesc>Atomicity of updates, roll backs, and what happens to indexes when

    14 a rollback happens are covered in this document.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <p>The store database, <codeph>RDbStoreDatabase</codeph>, runs completely

    16 client side and requires the user program to provide a store for its operations.

    17 For this reason, isolation, concurrency and serializability are not issues

    18 for the transaction model. However, support for multiple rowsets concurrently

    19 updating the same table is provided, and the rowset cursors attempt to maintain

    20 their current position through such (potentially conflicting) updates.</p>

    21 <p>Transactions on a store database do guarantee atomicity of updates. As <codeph>RDbStoreDatabase</codeph> is

    22 designed to be a small-scale relational database, it does not make sense for

    23 it to use transaction systems more suited to large server hosted databases.

    24 Instead of using a logfile, the store database provides transaction support

    25 by using the commit and revert functionality of <codeph>CStreamStore</codeph>.

    26 If the actual store class does not support this protocol, then it cannot be

    27 used as a basis for a DBMS store database. Practically, this means that store

    28 databases are permanent file stores, i.e. <codeph>CPermanentFileStore</codeph>.</p>

    29 <p>Successful transaction support by <codeph>RDbStoreDatabase</codeph> requires

    30 that <i>the client must not call </i> <codeph>CommitL()</codeph> <i> and </i> <codeph>Revert()</codeph> <i> on

    31 the store while the database is open</i>. Should a client need to modify its

    32 own stream data using the store's commit/revert protocol while a database

    33 is open, it can enclose the stream operations within a database transaction,

    34 using rollback on error; this achieves an equivalent result. Such store operations

    35 can be combined with database updates within a transaction to ensure that

    36 the separate updates are treated atomically.</p>

    37 <p>Committing a transaction leaves all open rowsets in a valid state. How

    38 and when updates are reflected within those rowsets depends on how they have

    39 been evaluated. </p>

    40 <p>Rolling back a transaction causes all rowsets on the database to lose their

    41 current place. All rowsets must be reset and possibly be re-evaluated before

    42 they can be used again. However, they do not need to be opened or prepared

    43 again.</p>

    44 <p>Indexes cannot be recovered easily on rollback, so they are marked as unusable,

    45 and the database is marked as damaged. Tables and untouched indexes continue

    46 to operate as before. Recovering the database restores the damaged indexes

    47 fully. </p>

    48 <p>For multiple updates, explicitly using a transaction can also reduce the

    49 time required by a factor of more than 50. It also reduces the transient store

    50 size requirement by a factor of more than 6 — compaction of the store results

    51 in similar sizes for updates whether or not a transaction was used.</p>

    52 </conbody></concept>