!C99Shell v. 1.0 pre-release build #13!

Software: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.54 OpenSSL/0.9.7l DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0 mod_gzip/2.0.26.1a 

uname -a: Linux snow.he.net 4.4.276-v2-mono-1 #1 SMP Wed Jul 21 11:21:17 PDT 2021 i686 

uid=99(nobody) gid=98(nobody) groups=98(nobody) 

Safe-mode: OFF (not secure)

/usr/doc/db-3.3.11/ref/transapp/   drwxr-xr-x
Free 318.32 GB of 458.09 GB (69.49%)
Home    Back    Forward    UPDIR    Refresh    Search    Buffer    Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    


Viewing file:     why.html (3.1 KB)      -rw-r--r--
Select action/file-type:
(+) | (+) | (+) | Code (+) | Session (+) | (+) | SDB (+) | (+) | (+) | (+) | (+) | (+) |
Berkeley DB Reference Guide: Why transactions?

Berkeley DB Reference Guide:
Berkeley DB Transactional Data Store Applications

PrevRefNext

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.

PrevRefNext

Copyright Sleepycat Software


:: Command execute ::

Enter:
 
Select:
 

:: Search ::
  - regexp 

:: Upload ::
 
[ Read-Only ]

:: Make Dir ::
 
[ Read-Only ]
:: Make File ::
 
[ Read-Only ]

:: Go Dir ::
 
:: Go File ::
 

--[ c99shell v. 1.0 pre-release build #13 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.02 ]--