#include <dbtransaction.hxx>
Inheritance diagram for pqxx::dbtransaction:
Protected Member Functions | |
| dbtransaction (connection_base &, const PGSTD::string &IsolationString, const PGSTD::string &NName, const PGSTD::string &CName) | |
| void | start_backend_transaction () |
| Start a transaction on the backend and set desired isolation level. | |
Use a dbtransaction-derived object such as "work" (transaction<>) to enclose operations on a database in a single "unit of work." This ensures that the whole series of operations either succeeds as a whole or fails completely. In no case will it leave half-finished work behind in the database.
Once processing on a transaction has succeeded and any changes should be allowed to become permanent in the database, call Commit(). If something has gone wrong and the changes should be forgotten, call Abort() instead. If you do neither, an implicit Abort() is executed at destruction time.
It is an error to abort a transaction that has already been committed, or to commit a transaction that has already been aborted. Aborting an already aborted transaction or committing an already committed one has been allowed to make errors easier to deal with. Repeated aborts or commits have no effect after the first one.
Database transactions are not suitable for guarding long-running processes. If your transaction code becomes too long or too complex, please consider ways to break it up into smaller ones. There's no easy, general way to do this since application-specific considerations become important at this point.
The actual operations for beginning and committing/aborting the backend transaction are implemented by a derived class. The implementing concrete class must also call Begin() and End() from its constructors and destructors, respectively, and implement DoExec().
|
||||||||||||||||||||
|
|
|
|
Start a transaction on the backend and set desired isolation level.
|
1.3.9.1