libpqxx
pqxx::transactor< TRANSACTION > Class Template Reference

#include <transactor.hxx>

Public Types

using argument_type = TRANSACTION
 

Public Member Functions

 transactor (const std::string &TName="transactor")
 
void operator() (TRANSACTION &T)
 Overridable transaction definition; insert your database code here. More...
 
void on_abort (const char[]) noexcept
 Optional overridable function to be called if transaction is aborted. More...
 
void on_commit ()
 Optional overridable function to be called after successful commit. More...
 
void on_doubt () noexcept
 Overridable function to be called when "in doubt" about outcome. More...
 
std::string name () const
 The transactor's name. More...
 

Detailed Description

template<typename TRANSACTION = transaction<read_committed>>
class pqxx::transactor< TRANSACTION >
Deprecated:
Pre-C++11 wrapper for automatically retrying transactions.

Pass an object of your transactor-based class to connection_base::perform() to execute the transaction code embedded in it.

connection_base::perform() is actually a template, specializing itself to any transactor type you pass to it. This means you will have to pass it a reference of your object's ultimate static type; runtime polymorphism is not allowed. Hence the absence of virtual methods in transactor. The exact methods to be called at runtime must be resolved at compile time.

Your transactor-derived class must define a copy constructor. This will be used to create a "clean" copy of your transactor for every attempt that perform() makes to run it.

Member Typedef Documentation

◆ argument_type

template<typename TRANSACTION = transaction<read_committed>>
using pqxx::transactor< TRANSACTION >::argument_type = TRANSACTION

Constructor & Destructor Documentation

◆ transactor()

template<typename TRANSACTION = transaction<read_committed>>
pqxx::transactor< TRANSACTION >::transactor ( const std::string &  TName = "transactor< TRANSACTION >")
explicit

Member Function Documentation

◆ name()

template<typename TRANSACTION = transaction<read_committed>>
std::string pqxx::transactor< TRANSACTION >::name ( ) const

The transactor's name.

◆ on_abort()

template<typename TRANSACTION = transaction<read_committed>>
void pqxx::transactor< TRANSACTION >::on_abort ( const char  [])
noexcept

Optional overridable function to be called if transaction is aborted.

This need not imply complete failure; the transactor will automatically retry the operation a number of times before giving up. on_abort() will be called for each of the failed attempts.

One parameter is passed in by the framework: an error string describing why the transaction failed. This will also be logged to the connection's notice processor.

◆ on_commit()

template<typename TRANSACTION = transaction<read_committed>>
void pqxx::transactor< TRANSACTION >::on_commit ( )

Optional overridable function to be called after successful commit.

If your on_commit() throws an exception, the actual back-end transaction will remain committed, so any changes in the database remain regardless of how this function terminates.

◆ on_doubt()

template<typename TRANSACTION = transaction<read_committed>>
void pqxx::transactor< TRANSACTION >::on_doubt ( )
noexcept

Overridable function to be called when "in doubt" about outcome.

This may happen if the connection to the backend is lost while attempting to commit. In that case, the backend may have committed the transaction but is unable to confirm this to the frontend; or the transaction may have failed, causing it to be rolled back, but again without acknowledgement to the client program. The best way to deal with this situation is typically to wave red flags in the user's face and ask him to investigate.

The robusttransaction class is intended to reduce the chances of this error occurring, at a certain cost in performance.

See also
robusttransaction

◆ operator()()

template<typename TRANSACTION = transaction<read_committed>>
void pqxx::transactor< TRANSACTION >::operator() ( TRANSACTION &  T)

Overridable transaction definition; insert your database code here.

The operation will be retried if the connection to the backend is lost or the operation fails, but not if the connection is broken in such a way as to leave the library in doubt as to whether the operation succeeded. In that case, an in_doubt_error will be thrown.

Recommended practice is to allow this operator to modify only the transactor itself, and the dedicated transaction object it is passed as an argument. This is what makes side effects, retrying etc. controllable in the transactor framework.

Parameters
TDedicated transaction context created to perform this operation.

The documentation for this class was generated from the following file: