head 1.2;
access;
symbols
RPM_4_2_1:1.1.1.5
RPM_4_2:1.1.1.5
RPM_4_1_1:1.1.1.5
RPM_4_1:1.1.1.4
RPM_4_0_5:1.1.1.3
RPM_4_0_4:1.1.1.2
RPM_4_0_3:1.1.1.1
RPM:1.1.1;
locks; strict;
comment @# @;
1.2
date 2008.01.02.09.55.44; author rse; state dead;
branches;
next 1.1;
commitid z4cpSiAhOCXk5PLs;
1.1
date 2001.07.23.20.45.38; author rse; state Exp;
branches
1.1.1.1;
next ;
1.1.1.1
date 2001.07.23.20.45.38; author rse; state Exp;
branches;
next 1.1.1.2;
1.1.1.2
date 2002.01.08.00.30.12; author rse; state Exp;
branches;
next 1.1.1.3;
1.1.1.3
date 2003.01.18.13.49.03; author rse; state Exp;
branches;
next 1.1.1.4;
1.1.1.4
date 2001.05.13.19.58.47; author rse; state Exp;
branches;
next 1.1.1.5;
1.1.1.5
date 2003.01.18.14.05.00; author rse; state Exp;
branches;
next ;
desc
@@
1.2
log
@remove the ancient RPM 4.2.1 source tree copy
@
text
@
Berkeley DB Reference Guide: Why transactions?
- Berkeley DB Reference Guide:
- Berkeley DB Transactional Data Store Applications
|
  
|
Why transactions?
Perhaps the first question to answer is "Why transactions?" There are
a number of reasons to include transactional support in your applications.
The most common ones are the following:
- Recoverability
- Applications often need to ensure that no matter how the system or
application fails, previously saved data is available the next time the
application runs.
- Deadlock avoidance
- When multiple threads of control change the database at the same time,
there is usually the possibility of deadlock; that is, each of the
threads of control owns a resource another thread wants, so no thread
is able to make forward progress -- all waiting for a resource.
Deadlocks are resolved by having one of the operations involved release
the resources it controls so the other operations can proceed. (The
operation releasing its resources usually just tries again later.)
Transactions are necessary so that any changes that were already made
to the database can be undone as part of releasing the held resources.
- Atomicity
- Applications often need to make multiple changes to one or more
databases, but want to ensure that either all of the changes happen, or
none of them happens. Transactions guarantee that a group of changes
are atomic; that is, if the application or system fails, either all of
the changes to the databases will appear when the application next runs,
or none of them.
- Repeatable reads
- Applications sometimes need to ensure that while doing a group of
operations on a database, the value returned as a result of a database
retrieval doesn't change; that is, if you retrieve the same key more
than once, the data item will be the same each time. Transactions
guarantee this behavior.
Copyright Sleepycat Software
@
1.1
log
@Initial revision
@
text
@d1 1
a1 1
@
1.1.1.1
log
@Import: RPM 4.0.3
@
text
@@
1.1.1.2
log
@Import: RPM 4.0.4
@
text
@d1 1
a1 1
@
1.1.1.3
log
@Import: RPM 4.0.5
@
text
@d1 2
a2 2
a3 1
d24 20
a43 10
AtomicityApplications may need to make multiple changes to one or more databases,
but ensure that either all of the changes happen, or none of them
happens. Transactions guarantee that a group of changes are atomic;
that is, if the application or system fails, either all of the changes
to the databases will appear when the application next runs, or none of
them.
IsolationApplications may need to make changes in isolation, that is, ensure that
only a single thread of control is modifying a key/data pair at a time.
Transactions ensure each thread of control sees all records as if all
other transactions either completed before or after its transaction.
@
1.1.1.4
log
@Import: RPM 4.1
@
text
@d1 2
a2 2
d4 1
d25 10
a34 20
Deadlock avoidanceWhen multiple threads of control change the database at the same time,
there is usually the possibility of deadlock; that is, each of the
threads of control owns a resource another thread wants, so no thread
is able to make forward progress -- all waiting for a resource.
Deadlocks are resolved by having one of the operations involved release
the resources it controls so the other operations can proceed. (The
operation releasing its resources usually just tries again later.)
Transactions are necessary so that any changes that were already made
to the database can be undone as part of releasing the held resources.
AtomicityApplications often need to make multiple changes to one or more
databases, but want to ensure that either all of the changes happen, or
none of them happens. Transactions guarantee that a group of changes
are atomic; that is, if the application or system fails, either all of
the changes to the databases will appear when the application next runs,
or none of them.
Repeatable readsApplications sometimes need to ensure that while doing a group of
operations on a database, the value returned as a result of a database
retrieval doesn't change; that is, if you retrieve the same key more
than once, the data item will be the same each time. Transactions
guarantee this behavior.
@
1.1.1.5
log
@Import: RPM 4.1.1
@
text
@d1 2
a2 2
a3 1
d24 20
a43 10
AtomicityApplications may need to make multiple changes to one or more databases,
but ensure that either all of the changes happen, or none of them
happens. Transactions guarantee that a group of changes are atomic;
that is, if the application or system fails, either all of the changes
to the databases will appear when the application next runs, or none of
them.
IsolationApplications may need to make changes in isolation, that is, ensure that
only a single thread of control is modifying a key/data pair at a time.
Transactions ensure each thread of control sees all records as if all
other transactions either completed before or after its transaction.
@