The transactor framework also makes it easier for you to do this safely, avoiding typical pitfalls and encouraging programmers to separate their transaction definitions (essentially, business rules implementations) from their higher-level code (application using those business rules). The former go into the transactor-based class.
Pass an object of your transactor-based class to connection_base::perform() to execute the transaction code embedded in it (see the definitions in pqxx/connection_base.hxx).
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.