it obviously makes sense to keep the requirements on RMs/TMs as simple as possible, so sorry if I seem to attack every single one of your requirements. I only do this to make sure we don't introduce unnecessary requirements on every RM. Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
void rollback_only(); | void force_to_abort();
what's the difference between calling rollback() and calling rollback_only? I guess rollback_only() doesn't rollback immediatly but only marks the transaction and doesn't let you commit afterwards. but what is the benefit of that? example? what does commit() do after rollback_only() was called? throw? can't you then call rollback() instead of rollback_only() and let commit() throw when the transaction is already rolled back?
void restart();
we've discussed this shortly before, making RMs support restarting transactions is not trivial. it would mean that unspecified begin_root_transaction(); is changed to void begin_root_transaction(transaction &); and "transaction" must be DefaultConstructible. and every RM must support cleaning up a "transaction" object, possibly using a pointer to an internal transaction object or using boost::optional's internally to be able to re-construct it, if not all objects that are internally used can be cleared. do you really think this is worth having the small performance gain you talked about, ONLY in the case of an isolation_exception? if you need this for the purpose of the macro syntax only, you could wrap basic_transaction in a simple class like this: struct restartable_transaction{ void restart(){ tx=in_place(); } optional<basic_transaction> tx; }; I'd really like to keep this out of the RM requirements.
bool is_top_level();
what's top-level? root?
transaction_state status(); where enum transaction_state { active, marked_roolback_only, | forced_to_abort prepared, committed, rolledback, preparing, committing, rollingback ... }; or bool active(); bool marked_roolback_only() bool prepared() bool commited();
some of the status here seem to be "unstable" to me, i.e. would never be in effect while the user has a chance to query it. committing a transaction is a non-thread-safe operation (i.e., you can't commit in one thread and query the status of the transaction in another thread concurrently). so unless I'm missing something most of the listed status are never in effect when the caller has control. e.g., when would prepared() return true? what's left is: active, committed, rolledback, and possibly marked_rollback_only.