stldb::Transaction — Transaction represents the details of an in-progress transaction, including modifications which are in progress. A transaction is created by the Database class, acting as a factory. A Transaction is resolved by passing it to either the commit or rollback method of the Database. This was done to prevent the need for the Transaction type to itself be a template class.
// In header: </Users/bobw/workspace/stldb_lib/stldb/transaction.h> class Transaction { public: // construct/copy/destruct Transaction(); Transaction(const Transaction &); Transaction& operator=(const Transaction &); ~Transaction(); // public member functions template<typename ManagedRegionType, typename void_alloc_t, typename mutex_t> void commit(std::map< void *, container_proxy_base< ManagedRegionType > * > &, Logger< void_alloc_t, mutex_t > &, bool, commit_buffer_t< void_alloc_t > *) ; template<typename ManagedRegionType> void rollback(std::map< void *, container_proxy_base< ManagedRegionType > * > &) ; transaction_id_t getLockId() const; template<typename container_t> void insert_work_in_progress(container_t *, TransactionalOperation *) ; transactional_op_list & get_work_in_progress() ; template<typename T, typename container_t> T * getContainerSpecificData(container_t *) ; // private member functions void lock_database(boost::interprocess::interprocess_upgradable_mutex &) ; void unlock_database() ; };
Transaction
public
construct/copy/destructTransaction();
Transaction(const Transaction & t);
Transaction& operator=(const Transaction & t);
~Transaction();
Transaction
public member functionstemplate<typename ManagedRegionType, typename void_alloc_t, typename mutex_t> void commit(std::map< void *, container_proxy_base< ManagedRegionType > * > & proxies, Logger< void_alloc_t, mutex_t > & logger, bool diskless, commit_buffer_t< void_alloc_t > * buffer) ;
Most of the work associated with commit is actually done by the polymorphic TransactionalOperation objects which accumulate in the Transaction. Commit must lock each container in turn and hold all locks until all operations are done. (This is required to meet the ACI part of ACID.) To ensure that multiple commits don't deadlock, they all must consistently lock containers in the same order. The ordering of _outstandingChanges assures this.
Phase 3 - get a unique commit seq#, and put our commit buffer into the logging queue. At this point, we are reserving our place in the sequence of the log file.
Phase 4 - release all container locks. It is now acceptable for other threads to begin doing work on top of our committed data because they can't jump ahead of us in the logging queue.
template<typename ManagedRegionType> void rollback(std::map< void *, container_proxy_base< ManagedRegionType > * > & proxies) ;
Most of the work associated with rollback is likewise done by the polymorphic TransactionalOperation objects which accumulate in the Transaction.
transaction_id_t getLockId() const;Return the lock_id of this transaction.
template<typename container_t> void insert_work_in_progress(container_t * container, TransactionalOperation * op) ;
transactional_op_list & get_work_in_progress() ;
Returns the transactional_op_list of outstanding operations. There are some operations like swap() or clear() which might need to adjust information on previous operations against the same container as part of their implementation.
template<typename T, typename container_t> T * getContainerSpecificData(container_t * c) ;
Return the pending changes container (some subclass of PendingChangeSet) for the container ref passed. If none exists, and create_flag = true, create one.
Return the pending changes container (some subclass of PendingChangeSet) for the container ref passed. If none exists, and create_flag = true, create one. Note: Although this returns T*, the transaction object retains ownership of the object. When _pendingChanges is destroyed (by the transaction destructor), the boost::any values within that map are also destroyed which in turn destroys all container specific data held by the transaction.