qpid Namespace Reference

Represents a single transaction. More...


Classes

class  Exception
 Exception base class for all Qpid exceptions. More...
struct  ShutdownException
 Exception used to indicate that a thread should shut down. More...
struct  EmptyException
 Exception to indicate empty queue or other empty state. More...
class  ExceptionHolder
 Holder for a heap-allocated exc eption that can be stack allocated and thrown safely. More...
class  SharedObject
 Template to enforce shared object conventions. More...

Namespaces

namespace  client
 The client namespace contains all classes that make up a client implementation of the AMQP protocol.
namespace  framing
 The framing namespace contains classes that are used to create, send and receive the basic packets from which AMQP is built.

Functions

template<class T>
shared_ptr< T > make_shared_ptr (T *ptr)
template<class T, class D>
shared_ptr< T > make_shared_ptr (T *ptr, D deleter)


Detailed Description

Represents a single transaction.

As such, an instance of this class will hold a list of operations representing the workload of the transaction. This work can be committed or rolled back. Committing is a two-stage process: first all the operations should be prepared, then if that succeeds they can be committed.

In the 2pc case, a successful prepare may be followed by either a commit or a rollback.

Atomicity of prepare is ensured by using a lower level transactional facility. This saves explicitly rolling back all the successfully prepared ops when one of them fails. i.e. we do not use 2pc internally, we instead ensure that prepare is atomic at a lower level. This makes individual prepare operations easier to code.

Transactions on a messaging broker effect three types of 'action': (1) updates to persistent storage (2) updates to transient storage or cached data (3) network writes.

Of these, (1) should always occur atomically during prepare to ensure that if the broker crashes while a transaction is being completed the persistent state (which is all that then remains) is consistent. (3) can only be done on commit, after a successful prepare. There is a little more flexibility with (2) but any changes made during prepare should be subject to the control of the TransactionalStore in use.


Generated on Tue Apr 17 14:22:10 2007 for Qpid by  doxygen 1.4.7