Boost logo

Boost :

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-14 20:27:32

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_at_[hidden]>:
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at