client transaction

In the world of conventional (relational) databases,
transactions keep data consistent. Orphan records or
records with half-baked columns make a mess and confuse
the software. The idea behind transactions is to assemble
data in memory, set up the relations between them and
commit them to the database in their entirety when they
are fully initialized and have been bolted together. If
something goes wrong and objects can't be created as planned,
the database program simply does not commit anything and
leaves the database as it was. This atomicity and isolation
is also the central idea of re-store's transaction model.
In contrast to relational databases, re-store's client
transactions are not determined by how data is structured
or how it depends on other data. Instead, client transactions
are designed around what the user does. Usually a client
transaction (that's how re-store transactions are called)
spans a unit of work, and these client transaction can
embrace long and complicated operations. In order to
keep things clear, we will use the re-store term "client
transaction" to make these differences more explicit and
distinguish them from regular database transactions. Make
no mistake, however: behind the scenes, for actually persisting
data, the MS SQL Server uses common transactions, but their
nature and design is completely hidden from the programmer
who is working with re-store client transactions.