Here is an excerpt from my requirements doc:
Transactions
In addition to method calls, a session may include nested transactions. The
maximum number of transactions that can be nested is TBD. There are tokens in
the session stream that are transaction start and end tokens. The host is free
to start a transaction on a session between normal operations, and may
subsequently open nested transactions. All transactions consist of the
following steps:
1. The transaction is opened.
2. A set of operations are made.
3. The transaction is either aborted or committed.
If a transaction is aborted all database state is reset ("rolled-back") to its
value at the time the transaction was opened.
Nested transactions abort or commit relative to their parent transaction. In
the case of an aborted transaction, the database state is rolled back to the
point where the transaction was started. (This is true whether or not the
transaction is nested.) In the case of a commit, the nested transaction’s
changes
become part of its parent transaction, as if the nested transaction boundaries
had never been established.
A commit of a nested transaction does not make a commit that necessarily
persists since the parent transaction is not yet ended. All transactions must
be closed before data is written to the database. This may occur before the end
of a session.
The device must guarantee that a transaction completely commits to media
(persists) or completely aborts. This means that the device must arrange that
if a power cycle, reset, or other event, occurs in the middle of a commit, that
when the device comes back up the commit is either finished or all the changes
are aborted. This guarantees database consistency and prevents power-off or
reset attacks.
Ray
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
